archived WALL files question
archived WALL files question
am 15.04.2010 17:31:59 von Renato Oliveira
--_000_7965A9DCF12CC14984420BCC37B1608F25AC0B99ADElzargrantc ou_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Dear all,
I was reading again the documentation... "The archive command should genera=
lly de designed to refuse to overwrite any pre-existing archive file."
This means it will keep writing logs to the folder specified forever, and w=
ithout an intervention, the media will run out of space.
What do you guys do with regards to this situation, for example:
How to you clean up the old archived logs?
For example:
you archive your log files from your main Postgres server to a folder /mnt/=
pitr for example
You set your standby to pick the logs from /mnt/pitr, then it archives each=
log as it comes.
/mnt/pitr will fill up very quickly and run out of space if we don't have a=
process to DELETE/ARCHIEVE older logs.
I guess the process which picks up the logs for the standby server, needs t=
o take care of the logs, by deleting the older ones or by archiving them pe=
rmanently?
How do you guys deal with this problem?
Thank you very much in advance
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our website
..html>
--_000_7965A9DCF12CC14984420BCC37B1608F25AC0B99ADElzargrantc ou_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
osoft-com:office:access" xmlns:b=3D"urn:schemas-microsoft-com:office:publis=
her" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spread sheet" xml=
ns:D=3D"DAV:" xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/di r=
ectory/" xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http:=
//schemas.microsoft.com/sharepoint/dsp" xmlns:dssi=3D"http://schemas.micros=
oft.com/office/2006/digsig" xmlns:dsss=3D"http://schemas.microsoft.com/offi=
ce/2006/digsig-setup" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882=
" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:ex12m=3D"http://sche=
mas.microsoft.com/exchange/services/2006/messages" xmlns:ex12t=3D"http://sc=
hemas.microsoft.com/exchange/services/2006/types" xmlns:html=3D"http://www.=
w3.org/TR/REC-html40" xmlns:m=3D"http://schemas.microsoft.com/office/2004/1=
2/omml" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/200 6/digit=
al-signature" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/200 6=
/relationships" xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/me=
etings/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compa tibili=
ty/2006" xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:oa=3D"ur=
n:schemas-microsoft-com:office:activation" xmlns:odc=3D"urn:schemas-microso=
ft-com:office:odc" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soa=
p/ois/" xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:ppda=
=3D"http://www.passport.com/NameSpace.xsd" xmlns:pptsl=3D"http://schemas.mi=
crosoft.com/sharepoint/soap/SlideLibrary/" xmlns:q=3D"http://schemas.xmlsoa=
p.org/soap/envelope/" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" xml=
ns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:rtc=3D"http://microsoft.co=
m/officenet/conferencing" xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14=
882" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"htt=
p://schemas.microsoft.com/sharepoint/soap/" xmlns:spsl=3D"http://microsoft.=
com/webservices/SharePointPortalServer/PublishedLinksService " xmlns:spwp=3D=
"http://microsoft.com/sharepoint/webpartpages" xmlns:ss=3D"urn:schemas-micr=
osoft-com:office:spreadsheet" xmlns:st=3D"" xmlns:sub=3D"http://schemas=
..microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:udc=3D"http://schemas.=
microsoft.com/data/udc" xmlns:udcp2p=3D"http://schemas.microsoft.com/data/u=
dc/parttopart" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:v=3D"urn:=
schemas-microsoft-com:vml" xmlns:w=3D"urn:schemas-microsoft-com:office:word=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/wor kflow/" xmlns=
:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:x2=3D"http://schemas.mi=
crosoft.com/office/excel/2003/xml" xmlns:xsd=3D"http://www.w3.org/2001/XMLS=
chema" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" xmlns:Z=3D"u=
rn:schemas-microsoft-com:">
scii" http-equiv=3D"Content-Type">
>
Dear all,
I was reading again the documentation... “The ar=
chive
command should generally de designed to refuse to overwrite any pre-existin=
g
archive file.”
This means it will keep writing logs to the folder spe=
cified
forever, and without an intervention, the media will run out of space.=
What do you guys do with regards to this situation, fo=
r
example:
How to you clean up the old archived logs?<=
/p>
For example:
you archive your log files from your main Postgres ser=
ver to
a folder /mnt/pitr for example
You set your standby to pick the logs from /mnt/pitr, =
then
it archives each log as it comes.
/mnt/pitr will fill up very quickly and run out of spa=
ce if
we don’t have a process to DELETE/ARCHIEVE older logs.
I guess the process which picks up the logs for the st=
andby
server, needs to take care of the logs, by deleting the older ones or by
archiving them permanently?
How do you guys deal with this problem?
Thank you very much in advance
Best regards
Renato
Renato=
Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
FONT>
>
>
Tel: +=
44 (0)1763 260811
Fax: +44 (0)1763 262410
..co.uk/">www.grant.co.uk
>
Grant =
Instruments (Cambridge) Ltd
Company registered in England, re=
gistration number 658133
Registered office address:
29 Stat=
ion Road,
Shepreth,
CAMBS SG8 6GB
UK
>
ONT>
>
>
>
>
; COLOR: green; FONT-FAMILY: Webdings">
; COLOR: green; FONT-FAMILY: Webdings">P
=3D"EN-US" STYLE=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Verdana','=
sans-serif'">
OLOR: green; FONT-FAMILY: 'Arial','sans-serif'">Please consider the environ=
ment before printing this email
CONFIDENTIALITY: The =
information in this e-mail and any attachments is confidential. It is inten=
ded only for the named recipients(s). If you are not the named recipient pl=
ease notify the sender immediately and do not disclose the contents to anot=
her person or take copies.
VIRUSES: The contents=
of this e-mail or attachment(s) may contain viruses which could damage you=
r own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken e=
very reasonable precaution to minimise this risk, we cannot accept liabilit=
y for any damage which you sustain as a result of software viruses. You sho=
uld therefore carry out your own virus checks before opening the attachment=
(s).
OpenXML: For informat=
ion about the OpenXML file format in use within Grant Instruments please vi=
sit our =
--_000_7965A9DCF12CC14984420BCC37B1608F25AC0B99ADElzargrantc ou_--
Re: archived WALL files question
am 15.04.2010 17:56:44 von Scott Mead
--000e0cd18024a0a7720484488a65
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 15, 2010 at 11:31 AM, Renato Oliveira <
renato.oliveira@grant.co.uk> wrote:
> Dear all,
>
>
>
> I was reading again the documentation... =93The archive command should
> generally de designed to refuse to overwrite any pre-existing archive fil=
e.=94
>
> This means it will keep writing logs to the folder specified forever, and
> without an intervention, the media will run out of space.
>
>
>
> What do you guys do with regards to this situation, for example:
>
> How to you clean up the old archived logs?
>
>
>
> For example:
>
> you archive your log files from your main Postgres server to a folder
> /mnt/pitr for example
>
> You set your standby to pick the logs from /mnt/pitr, then it archives ea=
ch
> log as it comes.
>
> /mnt/pitr will fill up very quickly and run out of space if we don=92t ha=
ve a
> process to DELETE/ARCHIEVE older logs.
>
>
>
> I guess the process which picks up the logs for the standby server, needs
> to take care of the logs, by deleting the older ones or by archiving them
> permanently?
>
Depends on what it is you're trying to accomplish:
*) PITR slave server constantly applying logs
If all you want is a server to constantly apply the logs and you don't
care about them afterwards, look into the '%r' macro in pg_standby. It wil=
l
automatically archive files for you -- Of course, your standby instance
needs to have write access to the /mnt/pitr folder to delete from.
If you are using the archive_command to copy files in the /mnt/pitr
directory, and then doing a cron based copy to a backup server, have your
cronjob delete files from the primary after it is confirmed that the logs
got shipped safely to the backup.
*) Backup retention time
If you're trying to keep logs around so that you can do a point in time
recovery with old backups, you want to figure your retention times and
determine your RTO (http://en.wikipedia.org/wiki/Recovery_time_objective).
If you need to be able to recovery to any point in time for the past 1
week with a low RTO, then you want to keep that week's worth of logs
uncompressed and available. Anything beyond that, use a cron job to
compress the logs (they usually compress pretty well based on your data).
Basically, you need to keep all the low-RTO required logs around so
that you can quickly get at them. If you don't have any low RTO
requirements and you just want to keep a few weeks worth of data around, I
would recommend that you add a few lines of code to the end of your backup
job to compress (or you could delete if you don't want them) all the logs
prior to the backup that you are taking.
Hope this helps
--Scott
>
>
> How do you guys deal with this problem?
>
>
>
> Thank you very much in advance
>
>
>
> Best regards
>
>
>
> Renato
>
>
>
>
>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> www.grant.co.uk
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
>
>
>
>
> **
>
> *P** **Please consider the environment before printing this email*
> *CONFIDENTIALITY*: The information in this e-mail and any attachments is
> confidential. It is intended only for the named recipients(s). If you are
> not the named recipient please notify the sender immediately and do not
> disclose the contents to another person or take copies.
>
> **
> *VIRUSES:* The contents of this e-mail or attachment(s) may contain
> viruses which could damage your own computer system. Whilst Grant
> Instruments (Cambridge) Ltd has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should therefore carry out y=
our
> own virus checks before opening the attachment(s).
>
> *OpenXML*: For information about the OpenXML file format in use within
> Grant Instruments please visit our website
/openxml.html>
>
--000e0cd18024a0a7720484488a65
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 15, 2010 at 11:31 AM, Renato Oli=
veira
<=
renato.oliveira@grant.co.uk> wrote:
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex;">
Dear all,
=A0
I was reading again the documentation... =93The arch=
ive
command should generally de designed to refuse to overwrite any pre-existin=
g
archive file.=94
This means it will keep writing logs to the folder s=
pecified
forever, and without an intervention, the media will run out of space.
=A0
What do you guys do with regards to this situation, =
for
example:
How to you clean up the old archived logs?
=A0
For example:
you archive your log files from your main Postgres s=
erver to
a folder /mnt/pitr for example
You set your standby to pick the logs from /mnt/pitr=
, then
it archives each log as it comes.
/mnt/pitr will fill up very quickly and run out of s=
pace if
we don=92t have a process to DELETE/ARCHIEVE older logs.
=A0
I guess the process which picks up the logs for the =
standby
server, needs to take care of the logs, by deleting the older ones or by
archiving them permanently?
quote>
Depends on what it is you're trying to accomplish:
>
*) PITR slave server constantly applying log=
s
If all you want is a server to constantly apply =
the logs and you don't care about them afterwards, look into the '%=
r' macro in pg_standby. =A0It will automatically archive files for you =
-- Of course, your standby instance needs to have write access to the /mnt/=
pitr folder to delete from.
If you are using the archive_command to copy fil=
es in the /mnt/pitr directory, and then doing a cron based copy to a backup=
server, have your cronjob delete files from the primary after it is confir=
med that the logs got shipped safely to the backup.
*) Backup retention time
=A0=
=A0 If you're trying to keep logs around so that you can do a point in =
time recovery with old backups, you want to figure your retention times and=
determine your RTO (
objective">http://en.wikipedia.org/wiki/Recovery_time_object ive).
=A0 If you need to be able to recovery to any po=
int in time for the past 1 week with a low RTO, then you want to keep that =
week's worth of logs uncompressed and available. =A0Anything beyond tha=
t, use a cron job to compress the logs (they usually compress pretty well b=
ased on your data). =A0
=A0 Basically, you need to keep all the low-RTO =
required logs around so that you can quickly get at them. =A0If you don'=
;t have any low RTO requirements and you just want to keep a few weeks wort=
h of data around, I would recommend that you add a few lines of code to the=
end of your backup job to compress (or you could delete if you don't w=
ant them) all the logs prior to the backup that you are taking.
Hope this helps
--Scott
<=
div>=A0
order-left:1px #ccc solid;padding-left:1ex;">
pt;font-family:Courier New">
=A0
How do you guys deal with this problem?
=A0
Thank you very much in advance
=A0
Best regards
=A0
Renato
=A0
=A0
=A0
Renato=
Oliveira
Systems Administrator
e-mail:
eira@grant.co.uk" target=3D"_blank">renato.oliveira@grant.co.uk<=
/font>
t>
>=A0
Tel: +=
44 (0)1763 260811
Fax: +44 (0)1763 262410
..co.uk/" target=3D"_blank">www.grant.co.uk
>=A0
Grant =
Instruments (Cambridge) Ltd
=A0
Company registered in England, regis=
tration number 658133
=A0
Registered office address:
29 Station Ro=
ad,
Shepreth,
CAMBS SG8 6GB
UK
>
ont>=A0
>
>=A0
>
=A0
>
=A0
color:green;font-family:Webdings">=A0
color:green;font-family:Webdings">P
US" style=3D"font-size:10pt;color:black">
style=3D"font-size:7.5pt;color:green">Please consider the environment befor=
e printing this email
CONFIDENTIALITY: The =
information in this e-mail and any attachments is confidential. It is inten=
ded only for the named recipients(s). If you are not the named recipient pl=
ease notify the sender immediately and do not disclose the contents to anot=
her person or take copies.
=A0
VIRUSES: The contents=
of this e-mail or attachment(s) may contain viruses which could damage you=
r own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken e=
very reasonable precaution to minimise this risk, we cannot accept liabilit=
y for any damage which you sustain as a result of software viruses. You sho=
uld therefore carry out your own virus checks before opening the attachment=
(s).
=A0
OpenXML: For informat=
ion about the OpenXML file format in use within Grant Instruments please vi=
sit our
blank">website
--000e0cd18024a0a7720484488a65--
Re: archived WALL files question
am 15.04.2010 18:01:49 von Kevin Grittner
Renato Oliveira wrote:
> I was reading again the documentation... "The archive command
> should generally de designed to refuse to overwrite any
> pre-existing archive file." This means it will keep writing logs
> to the folder specified forever, and without an intervention, the
> media will run out of space.
Overwriting an existing file wouldn't help with that, since the
filenames keep changing. It might, for example, prevent
accidentally wiping out the WAL files from one database cluster with
WAL files from another by copying the postgresql.conf file and
neglecting to change the archive script.
> What do you guys do with regards to this situation, for example:
> How to you clean up the old archived logs?
We keep two weekly base backups and all the WAL files needed to
recover from the earlier of the two to present. We also keep an
archival copy of the first base backup of each month with just the
WAL files needed to start it. We delete WAL files when no longer
needed to support this retention policy. It's all pretty automatic
based on bash scripts run from cron jobs.
Of course, you'll want to tailor your strategy to your business
needs.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 15.04.2010 18:07:34 von Vitaly Burshteyn
This is a multi-part message in MIME format.
------_=_NextPart_001_01CADCB5.C2AD56D2
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: base64
V2UgbWFuYWdlIHRoZSBXQUwgZmlsZXMgdmlhIHNreXRvb2xzIFdBTE1HUg0K
DQpBcyBmYXIgYXMgbG9nIGZpbGVzIHdlIHJ1biBhIGJhY2t1cCBldmVyeSAz
IGhvdXNlIGFuZCBrZWVwIDEyIGhvdXNlcnMgd29ydGggb24gdGhlIHNlcnZl
ciwgZXZlcnl0aGluZyBlbHNlIGlzIHNlbnQgdG8gYW1hem9uIFMzIHZpYSBz
M3N5bmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
RnJvbTogcGdzcWwtYWRtaW4tb3duZXJAcG9zdGdyZXNxbC5vcmcgPHBnc3Fs
LWFkbWluLW93bmVyQHBvc3RncmVzcWwub3JnPiANClRvOiBSZW5hdG8gT2xp
dmVpcmEgPHJlbmF0by5vbGl2ZWlyYUBncmFudC5jby51az4gDQpDYzogcGdz
cWwtYWRtaW5AcG9zdGdyZXNxbC5vcmcgPHBnc3FsLWFkbWluQHBvc3RncmVz
cWwub3JnPiANClNlbnQ6IFRodSBBcHIgMTUgMTE6NTY6NDQgMjAxMA0KU3Vi
amVjdDogUmU6IFtBRE1JTl0gYXJjaGl2ZWQgV0FMTCBmaWxlcyBxdWVzdGlv
biANCg0KDQoNCk9uIFRodSwgQXByIDE1LCAyMDEwIGF0IDExOjMxIEFNLCBS
ZW5hdG8gT2xpdmVpcmEgPHJlbmF0by5vbGl2ZWlyYUBncmFudC5jby51az4g
d3JvdGU6DQoNCg0KCQ0KDQoJRGVhciBhbGwsDQoNCgkgDQoNCglJIHdhcyBy
ZWFkaW5nIGFnYWluIHRoZSBkb2N1bWVudGF0aW9uLi4uIOKAnFRoZSBhcmNo
aXZlIGNvbW1hbmQgc2hvdWxkIGdlbmVyYWxseSBkZSBkZXNpZ25lZCB0byBy
ZWZ1c2UgdG8gb3ZlcndyaXRlIGFueSBwcmUtZXhpc3RpbmcgYXJjaGl2ZSBm
aWxlLuKAnQ0KDQoJVGhpcyBtZWFucyBpdCB3aWxsIGtlZXAgd3JpdGluZyBs
b2dzIHRvIHRoZSBmb2xkZXIgc3BlY2lmaWVkIGZvcmV2ZXIsIGFuZCB3aXRo
b3V0IGFuIGludGVydmVudGlvbiwgdGhlIG1lZGlhIHdpbGwgcnVuIG91dCBv
ZiBzcGFjZS4NCg0KCSANCg0KCVdoYXQgZG8geW91IGd1eXMgZG8gd2l0aCBy
ZWdhcmRzIHRvIHRoaXMgc2l0dWF0aW9uLCBmb3IgZXhhbXBsZToNCg0KCUhv
dyB0byB5b3UgY2xlYW4gdXAgdGhlIG9sZCBhcmNoaXZlZCBsb2dzPw0KDQoJ
IA0KDQoJRm9yIGV4YW1wbGU6DQoNCgl5b3UgYXJjaGl2ZSB5b3VyIGxvZyBm
aWxlcyBmcm9tIHlvdXIgbWFpbiBQb3N0Z3JlcyBzZXJ2ZXIgdG8gYSBmb2xk
ZXIgL21udC9waXRyIGZvciBleGFtcGxlDQoNCglZb3Ugc2V0IHlvdXIgc3Rh
bmRieSB0byBwaWNrIHRoZSBsb2dzIGZyb20gL21udC9waXRyLCB0aGVuIGl0
IGFyY2hpdmVzIGVhY2ggbG9nIGFzIGl0IGNvbWVzLg0KDQoJL21udC9waXRy
IHdpbGwgZmlsbCB1cCB2ZXJ5IHF1aWNrbHkgYW5kIHJ1biBvdXQgb2Ygc3Bh
Y2UgaWYgd2UgZG9u4oCZdCBoYXZlIGEgcHJvY2VzcyB0byBERUxFVEUvQVJD
SElFVkUgb2xkZXIgbG9ncy4NCg0KCSANCg0KCUkgZ3Vlc3MgdGhlIHByb2Nl
c3Mgd2hpY2ggcGlja3MgdXAgdGhlIGxvZ3MgZm9yIHRoZSBzdGFuZGJ5IHNl
cnZlciwgbmVlZHMgdG8gdGFrZSBjYXJlIG9mIHRoZSBsb2dzLCBieSBkZWxl
dGluZyB0aGUgb2xkZXIgb25lcyBvciBieSBhcmNoaXZpbmcgdGhlbSBwZXJt
YW5lbnRseT8NCg0KRGVwZW5kcyBvbiB3aGF0IGl0IGlzIHlvdSdyZSB0cnlp
bmcgdG8gYWNjb21wbGlzaDoNCg0KDQoqKSBQSVRSIHNsYXZlIHNlcnZlciBj
b25zdGFudGx5IGFwcGx5aW5nIGxvZ3MNCg0KICAgSWYgYWxsIHlvdSB3YW50
IGlzIGEgc2VydmVyIHRvIGNvbnN0YW50bHkgYXBwbHkgdGhlIGxvZ3MgYW5k
IHlvdSBkb24ndCBjYXJlIGFib3V0IHRoZW0gYWZ0ZXJ3YXJkcywgbG9vayBp
bnRvIHRoZSAnJXInIG1hY3JvIGluIHBnX3N0YW5kYnkuICBJdCB3aWxsIGF1
dG9tYXRpY2FsbHkgYXJjaGl2ZSBmaWxlcyBmb3IgeW91IC0tIE9mIGNvdXJz
ZSwgeW91ciBzdGFuZGJ5IGluc3RhbmNlIG5lZWRzIHRvIGhhdmUgd3JpdGUg
YWNjZXNzIHRvIHRoZSAvbW50L3BpdHIgZm9sZGVyIHRvIGRlbGV0ZSBmcm9t
Lg0KDQogICBJZiB5b3UgYXJlIHVzaW5nIHRoZSBhcmNoaXZlX2NvbW1hbmQg
dG8gY29weSBmaWxlcyBpbiB0aGUgL21udC9waXRyIGRpcmVjdG9yeSwgYW5k
IHRoZW4gZG9pbmcgYSBjcm9uIGJhc2VkIGNvcHkgdG8gYSBiYWNrdXAgc2Vy
dmVyLCBoYXZlIHlvdXIgY3JvbmpvYiBkZWxldGUgZmlsZXMgZnJvbSB0aGUg
cHJpbWFyeSBhZnRlciBpdCBpcyBjb25maXJtZWQgdGhhdCB0aGUgbG9ncyBn
b3Qgc2hpcHBlZCBzYWZlbHkgdG8gdGhlIGJhY2t1cC4NCg0KKikgQmFja3Vw
IHJldGVudGlvbiB0aW1lDQoNCiAgIElmIHlvdSdyZSB0cnlpbmcgdG8ga2Vl
cCBsb2dzIGFyb3VuZCBzbyB0aGF0IHlvdSBjYW4gZG8gYSBwb2ludCBpbiB0
aW1lIHJlY292ZXJ5IHdpdGggb2xkIGJhY2t1cHMsIHlvdSB3YW50IHRvIGZp
Z3VyZSB5b3VyIHJldGVudGlvbiB0aW1lcyBhbmQgZGV0ZXJtaW5lIHlvdXIg
UlRPIChodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1JlY292ZXJ5X3Rp
bWVfb2JqZWN0aXZlKS4NCg0KICAgICBJZiB5b3UgbmVlZCB0byBiZSBhYmxl
IHRvIHJlY292ZXJ5IHRvIGFueSBwb2ludCBpbiB0aW1lIGZvciB0aGUgcGFz
dCAxIHdlZWsgd2l0aCBhIGxvdyBSVE8sIHRoZW4geW91IHdhbnQgdG8ga2Vl
cCB0aGF0IHdlZWsncyB3b3J0aCBvZiBsb2dzIHVuY29tcHJlc3NlZCBhbmQg
YXZhaWxhYmxlLiAgQW55dGhpbmcgYmV5b25kIHRoYXQsIHVzZSBhIGNyb24g
am9iIHRvIGNvbXByZXNzIHRoZSBsb2dzICh0aGV5IHVzdWFsbHkgY29tcHJl
c3MgcHJldHR5IHdlbGwgYmFzZWQgb24geW91ciBkYXRhKS4gIA0KDQogICAg
IEJhc2ljYWxseSwgeW91IG5lZWQgdG8ga2VlcCBhbGwgdGhlIGxvdy1SVE8g
cmVxdWlyZWQgbG9ncyBhcm91bmQgc28gdGhhdCB5b3UgY2FuIHF1aWNrbHkg
Z2V0IGF0IHRoZW0uICBJZiB5b3UgZG9uJ3QgaGF2ZSBhbnkgbG93IFJUTyBy
ZXF1aXJlbWVudHMgYW5kIHlvdSBqdXN0IHdhbnQgdG8ga2VlcCBhIGZldyB3
ZWVrcyB3b3J0aCBvZiBkYXRhIGFyb3VuZCwgSSB3b3VsZCByZWNvbW1lbmQg
dGhhdCB5b3UgYWRkIGEgZmV3IGxpbmVzIG9mIGNvZGUgdG8gdGhlIGVuZCBv
ZiB5b3VyIGJhY2t1cCBqb2IgdG8gY29tcHJlc3MgKG9yIHlvdSBjb3VsZCBk
ZWxldGUgaWYgeW91IGRvbid0IHdhbnQgdGhlbSkgYWxsIHRoZSBsb2dzIHBy
aW9yIHRvIHRoZSBiYWNrdXAgdGhhdCB5b3UgYXJlIHRha2luZy4NCg0KSG9w
ZSB0aGlzIGhlbHBzDQoNCi0tU2NvdHQNCiANCg0KCQ0KDQoJIA0KDQoJSG93
IGRvIHlvdSBndXlzIGRlYWwgd2l0aCB0aGlzIHByb2JsZW0/DQoNCgkgDQoN
CglUaGFuayB5b3UgdmVyeSBtdWNoIGluIGFkdmFuY2UNCg0KCSANCg0KCUJl
c3QgcmVnYXJkcw0KDQoJIA0KDQoJUmVuYXRvDQoNCgkgDQoNCgkgDQoNCgkg
DQoJUmVuYXRvIE9saXZlaXJhDQoJU3lzdGVtcyBBZG1pbmlzdHJhdG9yDQoJ
ZS1tYWlsOiByZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWsNCgkgDQoJVGVs
OiArNDQgKDApMTc2MyAyNjA4MTENCglGYXg6ICs0NCAoMCkxNzYzIDI2MjQx
MA0KCXd3dy5ncmFudC5jby51ayA8aHR0cDovL3d3dy5ncmFudC5jby51ay8+
IA0KCSANCglHcmFudCBJbnN0cnVtZW50cyAoQ2FtYnJpZGdlKSBMdGQgDQoJ
IA0KCUNvbXBhbnkgcmVnaXN0ZXJlZCBpbiBFbmdsYW5kLCByZWdpc3RyYXRp
b24gbnVtYmVyIDY1ODEzMw0KCSANCglSZWdpc3RlcmVkIG9mZmljZSBhZGRy
ZXNzOg0KCTI5IFN0YXRpb24gUm9hZCwgDQoJU2hlcHJldGgsIA0KCUNBTUJT
IFNHOCA2R0IgDQoJVUsNCgkgDQoJDQoJIA0KCQ0KCSANCgkNCgkgDQoNCgkg
DQoNCglQIFBsZWFzZSBjb25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3Jl
IHByaW50aW5nIHRoaXMgZW1haWwNCg0KCUNPTkZJREVOVElBTElUWTogVGhl
IGluZm9ybWF0aW9uIGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu
dHMgaXMgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0
aGUgbmFtZWQgcmVjaXBpZW50cyhzKS4gSWYgeW91IGFyZSBub3QgdGhlIG5h
bWVkIHJlY2lwaWVudCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp
YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW5v
dGhlciBwZXJzb24gb3IgdGFrZSBjb3BpZXMuIA0KCSANCgkNCglWSVJVU0VT
OiBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgb3IgYXR0YWNobWVudChz
KSBtYXkgY29udGFpbiB2aXJ1c2VzIHdoaWNoIGNvdWxkIGRhbWFnZSB5b3Vy
IG93biBjb21wdXRlciBzeXN0ZW0uIFdoaWxzdCBHcmFudCBJbnN0cnVtZW50
cyAoQ2FtYnJpZGdlKSBMdGQgaGFzIHRha2VuIGV2ZXJ5IHJlYXNvbmFibGUg
cHJlY2F1dGlvbiB0byBtaW5pbWlzZSB0aGlzIHJpc2ssIHdlIGNhbm5vdCBh
Y2NlcHQgbGlhYmlsaXR5IGZvciBhbnkgZGFtYWdlIHdoaWNoIHlvdSBzdXN0
YWluIGFzIGEgcmVzdWx0IG9mIHNvZnR3YXJlIHZpcnVzZXMuIFlvdSBzaG91
bGQgdGhlcmVmb3JlIGNhcnJ5IG91dCB5b3VyIG93biB2aXJ1cyBjaGVja3Mg
YmVmb3JlIG9wZW5pbmcgdGhlIGF0dGFjaG1lbnQocykuDQoJIA0KCQ0KCU9w
ZW5YTUw6IEZvciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgT3BlblhNTCBmaWxl
IGZvcm1hdCBpbiB1c2Ugd2l0aGluIEdyYW50IEluc3RydW1lbnRzIHBsZWFz
ZSB2aXNpdCBvdXIgd2Vic2l0ZSA8aHR0cDovL3d3dy5ncmFudC5jby51ay9T
dXBwb3J0L29wZW54bWwuaHRtbD4gDQoNCg0KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBtYXkgY29udGFpbiBwcml2aWxlZ2Vk
IA0KYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gIEl0IGlzIGludGVu
ZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIA0KcGVyc29uKHMpIG5hbWVk
IGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50
LCAgeW91IGFyZSANCmhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXZpZXcs
IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciANCmR1cGxpY2F0aW9u
IG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVk
LiBJZiB5b3UgYXJlIA0Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs
ZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgDQphbmQg
ZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo=
------_=_NextPart_001_01CADCB5.C2AD56D2
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: base64
PHA+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NCldlIG1h
bmFnZSB0aGUgV0FMIGZpbGVzIHZpYSBza3l0b29scyBXQUxNR1I8YnI+PGJy
PkFzIGZhciBhcyBsb2cgZmlsZXMgd2UgcnVuIGEgYmFja3VwIGV2ZXJ5IDMg
aG91c2UgYW5kIGtlZXAgMTIgaG91c2VycyB3b3J0aCBvbiB0aGUgc2VydmVy
LCBldmVyeXRoaW5nIGVsc2UgaXMgc2VudCB0byBhbWF6b24gUzMgdmlhIHMz
c3luYzwvZm9udD48L3A+DQo8cD48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBh
bGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBmYWNlPVRhaG9tYSBz
aXplPTI+DQo8Yj5Gcm9tPC9iPjogcGdzcWwtYWRtaW4tb3duZXJAcG9zdGdy
ZXNxbC5vcmcgJmx0O3Bnc3FsLWFkbWluLW93bmVyQHBvc3RncmVzcWwub3Jn
Jmd0Ow08YnI+PGI+VG88L2I+OiBSZW5hdG8gT2xpdmVpcmEgJmx0O3JlbmF0
by5vbGl2ZWlyYUBncmFudC5jby51ayZndDsNPGJyPjxiPkNjPC9iPjogcGdz
cWwtYWRtaW5AcG9zdGdyZXNxbC5vcmcgJmx0O3Bnc3FsLWFkbWluQHBvc3Rn
cmVzcWwub3JnJmd0Ow08YnI+PGI+U2VudDwvYj46IFRodSBBcHIgMTUgMTE6
NTY6NDQgMjAxMDxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtBRE1JTl0gYXJj
aGl2ZWQgV0FMTCBmaWxlcyBxdWVzdGlvbg08YnI+PC9mb250PjwvcD4NCjxi
cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBBcHIgMTUsIDIw
MTAgYXQgMTE6MzEgQU0sIFJlbmF0byBPbGl2ZWlyYSA8c3BhbiBkaXI9Imx0
ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpyZW5hdG8ub2xpdmVpcmFAZ3JhbnQu
Y28udWsiPnJlbmF0by5vbGl2ZWlyYUBncmFudC5jby51azwvYT4mZ3Q7PC9z
cGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl
IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj
Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPg0KDQoNCg0KDQoNCg0KDQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpD
b3VyaWVyIE5ldyI+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJBcmlhbCIg
c2l6ZT0iMiI+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRl
YXIgYWxsLDwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoN
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHJlYWRpbmcgYWdhaW4gdGhl
IGRvY3VtZW50YXRpb24uLi4g4oCcVGhlIGFyY2hpdmUNCmNvbW1hbmQgc2hv
dWxkIGdlbmVyYWxseSBkZSBkZXNpZ25lZCB0byByZWZ1c2UgdG8gb3Zlcndy
aXRlIGFueSBwcmUtZXhpc3RpbmcNCmFyY2hpdmUgZmlsZS7igJ08L3A+DQoN
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVhbnMgaXQgd2lsbCBrZWVw
IHdyaXRpbmcgbG9ncyB0byB0aGUgZm9sZGVyIHNwZWNpZmllZA0KZm9yZXZl
ciwgYW5kIHdpdGhvdXQgYW4gaW50ZXJ2ZW50aW9uLCB0aGUgbWVkaWEgd2ls
bCBydW4gb3V0IG9mIHNwYWNlLjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+wqA8L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8geW91
IGd1eXMgZG8gd2l0aCByZWdhcmRzIHRvIHRoaXMgc2l0dWF0aW9uLCBmb3IN
CmV4YW1wbGU6PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgdG8g
eW91IGNsZWFuIHVwIHRoZSBvbGQgYXJjaGl2ZWQgbG9ncz88L3A+DQoNCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPsKgPC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Gb3IgZXhhbXBsZTo8L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PnlvdSBhcmNoaXZlIHlvdXIgbG9nIGZpbGVzIGZyb20geW91ciBtYWluIFBv
c3RncmVzIHNlcnZlciB0bw0KYSBmb2xkZXIgL21udC9waXRyIGZvciBleGFt
cGxlPC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Ugc2V0IHlvdXIg
c3RhbmRieSB0byBwaWNrIHRoZSBsb2dzIGZyb20gL21udC9waXRyLCB0aGVu
DQppdCBhcmNoaXZlcyBlYWNoIGxvZyBhcyBpdCBjb21lcy48L3A+DQoNCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPi9tbnQvcGl0ciB3aWxsIGZpbGwgdXAgdmVy
eSBxdWlja2x5IGFuZCBydW4gb3V0IG9mIHNwYWNlIGlmDQp3ZSBkb27igJl0
IGhhdmUgYSBwcm9jZXNzIHRvIERFTEVURS9BUkNISUVWRSBvbGRlciBsb2dz
LjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoNCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhlIHByb2Nlc3Mgd2hpY2ggcGlj
a3MgdXAgdGhlIGxvZ3MgZm9yIHRoZSBzdGFuZGJ5DQpzZXJ2ZXIsIG5lZWRz
IHRvIHRha2UgY2FyZSBvZiB0aGUgbG9ncywgYnkgZGVsZXRpbmcgdGhlIG9s
ZGVyIG9uZXMgb3IgYnkNCmFyY2hpdmluZyB0aGVtIHBlcm1hbmVudGx5Pzwv
cD48L2Rpdj48L2ZvbnQ+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9j
a3F1b3RlPjxkaXY+RGVwZW5kcyBvbiB3aGF0IGl0IGlzIHlvdSYjMzk7cmUg
dHJ5aW5nIHRvIGFjY29tcGxpc2g6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp
dj48YnI+PC9kaXY+PGRpdj4qKSBQSVRSIHNsYXZlIHNlcnZlciBjb25zdGFu
dGx5IGFwcGx5aW5nIGxvZ3M8L2Rpdj4NCjxkaXY+PGJyPjwvZGl2PjxkaXY+
wqDCoCBJZiBhbGwgeW91IHdhbnQgaXMgYSBzZXJ2ZXIgdG8gY29uc3RhbnRs
eSBhcHBseSB0aGUgbG9ncyBhbmQgeW91IGRvbiYjMzk7dCBjYXJlIGFib3V0
IHRoZW0gYWZ0ZXJ3YXJkcywgbG9vayBpbnRvIHRoZSAmIzM5OyVyJiMzOTsg
bWFjcm8gaW4gcGdfc3RhbmRieS4gwqBJdCB3aWxsIGF1dG9tYXRpY2FsbHkg
YXJjaGl2ZSBmaWxlcyBmb3IgeW91IC0tIE9mIGNvdXJzZSwgeW91ciBzdGFu
ZGJ5IGluc3RhbmNlIG5lZWRzIHRvIGhhdmUgd3JpdGUgYWNjZXNzIHRvIHRo
ZSAvbW50L3BpdHIgZm9sZGVyIHRvIGRlbGV0ZSBmcm9tLjwvZGl2Pg0KPGRp
dj48YnI+PC9kaXY+PGRpdj7CoMKgIElmIHlvdSBhcmUgdXNpbmcgdGhlIGFy
Y2hpdmVfY29tbWFuZCB0byBjb3B5IGZpbGVzIGluIHRoZSAvbW50L3BpdHIg
ZGlyZWN0b3J5LCBhbmQgdGhlbiBkb2luZyBhIGNyb24gYmFzZWQgY29weSB0
byBhIGJhY2t1cCBzZXJ2ZXIsIGhhdmUgeW91ciBjcm9uam9iIGRlbGV0ZSBm
aWxlcyBmcm9tIHRoZSBwcmltYXJ5IGFmdGVyIGl0IGlzIGNvbmZpcm1lZCB0
aGF0IHRoZSBsb2dzIGdvdCBzaGlwcGVkIHNhZmVseSB0byB0aGUgYmFja3Vw
LjwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGRpdj4qKSBCYWNrdXAgcmV0ZW50
aW9uIHRpbWU8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PsKgwqAgSWYgeW91
JiMzOTtyZSB0cnlpbmcgdG8ga2VlcCBsb2dzIGFyb3VuZCBzbyB0aGF0IHlv
dSBjYW4gZG8gYSBwb2ludCBpbiB0aW1lIHJlY292ZXJ5IHdpdGggb2xkIGJh
Y2t1cHMsIHlvdSB3YW50IHRvIGZpZ3VyZSB5b3VyIHJldGVudGlvbiB0aW1l
cyBhbmQgZGV0ZXJtaW5lIHlvdXIgUlRPICg8YSBocmVmPSJodHRwOi8vZW4u
d2lraXBlZGlhLm9yZy93aWtpL1JlY292ZXJ5X3RpbWVfb2JqZWN0aXZlIj5o
dHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1JlY292ZXJ5X3RpbWVfb2Jq
ZWN0aXZlPC9hPikuPC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PsKgwqAg
wqAgSWYgeW91IG5lZWQgdG8gYmUgYWJsZSB0byByZWNvdmVyeSB0byBhbnkg
cG9pbnQgaW4gdGltZSBmb3IgdGhlIHBhc3QgMSB3ZWVrIHdpdGggYSBsb3cg
UlRPLCB0aGVuIHlvdSB3YW50IHRvIGtlZXAgdGhhdCB3ZWVrJiMzOTtzIHdv
cnRoIG9mIGxvZ3MgdW5jb21wcmVzc2VkIGFuZCBhdmFpbGFibGUuIMKgQW55
dGhpbmcgYmV5b25kIHRoYXQsIHVzZSBhIGNyb24gam9iIHRvIGNvbXByZXNz
IHRoZSBsb2dzICh0aGV5IHVzdWFsbHkgY29tcHJlc3MgcHJldHR5IHdlbGwg
YmFzZWQgb24geW91ciBkYXRhKS4gwqA8L2Rpdj4NCjxkaXY+PGJyPjwvZGl2
PjxkaXY+wqDCoCDCoCBCYXNpY2FsbHksIHlvdSBuZWVkIHRvIGtlZXAgYWxs
IHRoZSBsb3ctUlRPIHJlcXVpcmVkIGxvZ3MgYXJvdW5kIHNvIHRoYXQgeW91
IGNhbiBxdWlja2x5IGdldCBhdCB0aGVtLiDCoElmIHlvdSBkb24mIzM5O3Qg
aGF2ZSBhbnkgbG93IFJUTyByZXF1aXJlbWVudHMgYW5kIHlvdSBqdXN0IHdh
bnQgdG8ga2VlcCBhIGZldyB3ZWVrcyB3b3J0aCBvZiBkYXRhIGFyb3VuZCwg
SSB3b3VsZCByZWNvbW1lbmQgdGhhdCB5b3UgYWRkIGEgZmV3IGxpbmVzIG9m
IGNvZGUgdG8gdGhlIGVuZCBvZiB5b3VyIGJhY2t1cCBqb2IgdG8gY29tcHJl
c3MgKG9yIHlvdSBjb3VsZCBkZWxldGUgaWYgeW91IGRvbiYjMzk7dCB3YW50
IHRoZW0pIGFsbCB0aGUgbG9ncyBwcmlvciB0byB0aGUgYmFja3VwIHRoYXQg
eW91IGFyZSB0YWtpbmcuPC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2Pkhv
cGUgdGhpcyBoZWxwczwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LS1TY290
dDwvZGl2PjxkaXY+wqA8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf
cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox
cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+PGRpdj48ZGl2IHN0
eWxlPSJmb250LXNpemU6OXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIgTmV3Ij4N
CjxkaXY+PGRpdj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGRpdj4N
Cg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoNCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkhvdyBkbyB5b3UgZ3V5cyBkZWFsIHdpdGggdGhpcyBwcm9i
bGVtPzwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoNCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggaW4gYWR2
YW5jZTwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoNCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkczwvcD4NCg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlJlbmF0bzwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQoN
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPsKgPC9wPg0KDQo8L2Rpdj4NCg0KPC9m
b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+
PC9mb250PsKgPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkFyaWFsIiBzaXpl
PSIyIj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+UmVuYXRvIE9saXZl
aXJhPGJyPlN5c3RlbXMgQWRtaW5pc3RyYXRvcjxicj5lLW1haWw6IDxhIGhy
ZWY9Im1haWx0bzpyZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWsiIHRhcmdl
dD0iX2JsYW5rIj5yZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWs8L2E+PC9m
b250PjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGZvbnQg
ZmFjZT0iQXJpYWwiIHNpemU9IjIiPjwvZm9udD48L2ZvbnQ+PC9kaXY+DQoN
CjxkaXY+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxmb250IGZhY2U9
IkFyaWFsIiBzaXplPSIyIj48L2ZvbnQ+PC9mb250PsKgPC9kaXY+DQo8ZGl2
Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Zm9udCBmYWNlPSJBcmlh
bCIgc2l6ZT0iMiI+VGVsOiArNDQgKDApMTc2MyAyNjA4MTE8YnI+RmF4OiAr
NDQgKDApMTc2MyAyNjI0MTA8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5ncmFu
dC5jby51ay8iIHRhcmdldD0iX2JsYW5rIj53d3cuZ3JhbnQuY28udWs8L2E+
PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQXJpYWwi
IHNpemU9IjIiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48L2ZvbnQ+
PC9mb250PsKgPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkFyaWFsIiBzaXpl
PSIyIj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+R3JhbnQgSW5zdHJ1
bWVudHMgKENhbWJyaWRnZSkgTHRkIDxicj7CoDxicj5Db21wYW55IHJlZ2lz
dGVyZWQgaW4gRW5nbGFuZCwgcmVnaXN0cmF0aW9uIG51bWJlciA2NTgxMzM8
YnI+wqA8YnI+UmVnaXN0ZXJlZCBvZmZpY2UgYWRkcmVzczo8YnI+MjkgU3Rh
dGlvbiBSb2FkLCA8YnI+DQpTaGVwcmV0aCwgPGJyPkNBTUJTIFNHOCA2R0Ig
PGJyPlVLPC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i
QXJpYWwiIHNpemU9IjIiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48
L2ZvbnQ+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Zm9u
dCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PC9mb250PjwvZm9udD7CoDwvZGl2
Pg0KPGRpdj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGZvbnQgZmFj
ZT0iQXJpYWwiIHNpemU9IjIiPjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2
Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Zm9udCBmYWNlPSJBcmlh
bCIgc2l6ZT0iMiI+PC9mb250PjwvZm9udD7CoDwvZGl2Pg0KPGRpdj48Zm9u
dCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGZvbnQgZmFjZT0iQXJpYWwiIHNp
emU9IjIiPjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2PsKgPC9kaXY+DQo8
ZGl2Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48Zm9udCBmYWNlPSJB
cmlhbCIgc2l6ZT0iMiI+PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+wqA8
L2Rpdj4gPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGVt
PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE4cHQ7
Y29sb3I6Z3JlZW47Zm9udC1mYW1pbHk6V2ViZGluZ3MiPjwvc3Bhbj48L2I+
PC9lbT7CoDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxlbT48Yj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxOHB0O2NvbG9yOmdy
ZWVuO2ZvbnQtZmFtaWx5OldlYmRpbmdzIj5QPC9zcGFuPjwvYj48L2VtPjxl
bT48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMHB0
O2NvbG9yOmJsYWNrIj4gPC9zcGFuPjwvYj48L2VtPjxzdHJvbmc+PGk+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpncmVlbiI+UGxlYXNl
IGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcgdGhp
cyBlbWFpbDwvc3Bhbj48L2k+PC9zdHJvbmc+PC9wPg0KPC9kaXY+DQo8ZGl2
Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3Ryb25nPkNPTkZJREVO
VElBTElUWTwvc3Ryb25nPjogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZS1t
YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsLiBJdCBp
cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgbmFtZWQgcmVjaXBpZW50cyhzKS4g
SWYgeW91IGFyZSBub3QgdGhlIG5hbWVkIHJlY2lwaWVudCBwbGVhc2Ugbm90
aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z
ZSB0aGUgY29udGVudHMgdG8gYW5vdGhlciBwZXJzb24gb3IgdGFrZSBjb3Bp
ZXMuIDwvZm9udD48L2Rpdj4NCg0KPGRpdj48Zm9udCBmYWNlPSJBcmlhbCIg
c2l6ZT0iMiI+PC9mb250PsKgPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkFy
aWFsIiBzaXplPSIyIj48c3Ryb25nPjwvc3Ryb25nPjwvZm9udD48L2Rpdj4N
CjxkaXY+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzdHJvbmc+VklS
VVNFUzo8L3N0cm9uZz4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG9y
IGF0dGFjaG1lbnQocykgbWF5IGNvbnRhaW4gdmlydXNlcyB3aGljaCBjb3Vs
ZCBkYW1hZ2UgeW91ciBvd24gY29tcHV0ZXIgc3lzdGVtLiBXaGlsc3QgR3Jh
bnQgSW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRkIGhhcyB0YWtlbiBldmVy
eSByZWFzb25hYmxlIHByZWNhdXRpb24gdG8gbWluaW1pc2UgdGhpcyByaXNr
LCB3ZSBjYW5ub3QgYWNjZXB0IGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSB3
aGljaCB5b3Ugc3VzdGFpbiBhcyBhIHJlc3VsdCBvZiBzb2Z0d2FyZSB2aXJ1
c2VzLiBZb3Ugc2hvdWxkIHRoZXJlZm9yZSBjYXJyeSBvdXQgeW91ciBvd24g
dmlydXMgY2hlY2tzIGJlZm9yZSBvcGVuaW5nIHRoZSBhdHRhY2htZW50KHMp
LjwvZm9udD48L2Rpdj4NCg0KPGRpdj7CoDwvZGl2Pg0KPGRpdj48Zm9udCBm
YWNlPSJBcmlhbCIgc2l6ZT0iMiI+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u
dCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHN0cm9uZz5PcGVuWE1MPC9zdHJv
bmc+OiBGb3IgaW5mb3JtYXRpb24gYWJvdXQgdGhlIE9wZW5YTUwgZmlsZSBm
b3JtYXQgaW4gdXNlIHdpdGhpbiBHcmFudCBJbnN0cnVtZW50cyBwbGVhc2Ug
dmlzaXQgb3VyIDxhIGhyZWY9Imh0dHA6Ly93d3cuZ3JhbnQuY28udWsvU3Vw
cG9ydC9vcGVueG1sLmh0bWwiIHRhcmdldD0iX2JsYW5rIj53ZWJzaXRlPC9h
PjwvZm9udD48L2Rpdj4NCjwvZGl2PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPjwv
ZGl2Pjxicj4NCg==
------_=_NextPart_001_01CADCB5.C2AD56D2--
Re: archived WALL files question
am 16.04.2010 09:00:05 von Renato Oliveira
I am sorry Kevin, I really appreciate your experience and your knowledge, a=
nd that's why I am asking; I thought the base backup was only necessary onc=
e. For example once you have done your first base backup, that is it, all y=
ou need is to replay the logs and backup the logs.
What would be the reason(s) for you to do weekly base backups?
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
Sent: 15 April 2010 17:02
To: Renato Oliveira; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] archived WALL files question
Renato Oliveira wrote:
> I was reading again the documentation... "The archive command
> should generally de designed to refuse to overwrite any
> pre-existing archive file." This means it will keep writing logs
> to the folder specified forever, and without an intervention, the
> media will run out of space.
Overwriting an existing file wouldn't help with that, since the
filenames keep changing. It might, for example, prevent
accidentally wiping out the WAL files from one database cluster with
WAL files from another by copying the postgresql.conf file and
neglecting to change the archive script.
> What do you guys do with regards to this situation, for example:
> How to you clean up the old archived logs?
We keep two weekly base backups and all the WAL files needed to
recover from the earlier of the two to present. We also keep an
archival copy of the first base backup of each month with just the
WAL files needed to start it. We delete WAL files when no longer
needed to support this retention policy. It's all pretty automatic
based on bash scripts run from cron jobs.
Of course, you'll want to tailor your strategy to your business
needs.
-Kevin
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html
--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 16.04.2010 09:03:57 von Renato Oliveira
--_000_7965A9DCF12CC14984420BCC37B1608F25AC0B99E6Elzargrantc ou_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SSB3YXMgbG9va2luZyBpbnRvIFNreVRvb2xzLCBpdCBzb3VuZHMgcXVpdGUg Z29vZC4gSSBhbSBn
b2luZyB0byByZXZpc2l0IHRoaXMgUElUUiBzb2x1dGlvbiBvbmNlIGl0IGlz IGltcGxlbWVudGVk
IGZvciBzdXJlLg0KV2lsbCB0cnkgdG8ga2VlcCBhbiBleWUgYW5kIHNlZSBo b3cgaXQgZ29lcyBv
biBsaXZlIGFuZCBzZWUgd2hhdCB3ZSBuZWVkIHRvIGFkanVzdCBpbiB0aW1l Lg0KDQoNClRoYW5r
IHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgaGVscCByZWFsbHkgYXBwcmVjaWF0 ZWQgaXQuDQoNClJl
bmF0bw0KDQoNClJlbmF0byBPbGl2ZWlyYQ0KU3lzdGVtcyBBZG1pbmlzdHJh dG9yDQplLW1haWw6
IHJlbmF0by5vbGl2ZWlyYUBncmFudC5jby51aw0KDQpUZWw6ICs0NCAoMCkx NzYzIDI2MDgxMQ0K
RmF4OiArNDQgKDApMTc2MyAyNjI0MTANCnd3dy5ncmFudC5jby51azxodHRw Oi8vd3d3LmdyYW50
LmNvLnVrLz4NCg0KR3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRk DQoNCkNvbXBhbnkg
cmVnaXN0ZXJlZCBpbiBFbmdsYW5kLCByZWdpc3RyYXRpb24gbnVtYmVyIDY1 ODEzMw0KDQpSZWdp
c3RlcmVkIG9mZmljZSBhZGRyZXNzOg0KMjkgU3RhdGlvbiBSb2FkLA0KU2hl cHJldGgsDQpDQU1C
UyBTRzggNkdCDQpVSw0KDQoNCkZyb206IFZpdGFseSBCdXJzaHRleW4gW21h aWx0bzp2YnVyc2h0
ZXluQGJyb2Fkd2F5LmNvbV0NClNlbnQ6IDE1IEFwcmlsIDIwMTAgMTc6MDgN ClRvOiBzY290dC5s
aXN0c0BlbnRlcnByaXNlZGIuY29tOyBSZW5hdG8gT2xpdmVpcmENCkNjOiBw Z3NxbC1hZG1pbkBw
b3N0Z3Jlc3FsLm9yZw0KU3ViamVjdDogUmU6IFtBRE1JTl0gYXJjaGl2ZWQg V0FMTCBmaWxlcyBx
dWVzdGlvbg0KDQoNCldlIG1hbmFnZSB0aGUgV0FMIGZpbGVzIHZpYSBza3l0 b29scyBXQUxNR1IN
Cg0KQXMgZmFyIGFzIGxvZyBmaWxlcyB3ZSBydW4gYSBiYWNrdXAgZXZlcnkg MyBob3VzZSBhbmQg
a2VlcCAxMiBob3VzZXJzIHdvcnRoIG9uIHRoZSBzZXJ2ZXIsIGV2ZXJ5dGhp bmcgZWxzZSBpcyBz
ZW50IHRvIGFtYXpvbiBTMyB2aWEgczNzeW5jDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19f
X19fX19fDQpGcm9tOiBwZ3NxbC1hZG1pbi1vd25lckBwb3N0Z3Jlc3FsLm9y ZyA8cGdzcWwtYWRt
aW4tb3duZXJAcG9zdGdyZXNxbC5vcmc+DQpUbzogUmVuYXRvIE9saXZlaXJh IDxyZW5hdG8ub2xp
dmVpcmFAZ3JhbnQuY28udWs+DQpDYzogcGdzcWwtYWRtaW5AcG9zdGdyZXNx bC5vcmcgPHBnc3Fs
LWFkbWluQHBvc3RncmVzcWwub3JnPg0KU2VudDogVGh1IEFwciAxNSAxMTo1 Njo0NCAyMDEwDQpT
dWJqZWN0OiBSZTogW0FETUlOXSBhcmNoaXZlZCBXQUxMIGZpbGVzIHF1ZXN0 aW9uDQoNCk9uIFRo
dSwgQXByIDE1LCAyMDEwIGF0IDExOjMxIEFNLCBSZW5hdG8gT2xpdmVpcmEg PHJlbmF0by5vbGl2
ZWlyYUBncmFudC5jby51azxtYWlsdG86cmVuYXRvLm9saXZlaXJhQGdyYW50 LmNvLnVrPj4gd3Jv
dGU6DQpEZWFyIGFsbCwNCg0KSSB3YXMgcmVhZGluZyBhZ2FpbiB0aGUgZG9j dW1lbnRhdGlvbi4u
LiDigJxUaGUgYXJjaGl2ZSBjb21tYW5kIHNob3VsZCBnZW5lcmFsbHkgZGUg ZGVzaWduZWQgdG8g
cmVmdXNlIHRvIG92ZXJ3cml0ZSBhbnkgcHJlLWV4aXN0aW5nIGFyY2hpdmUg ZmlsZS7igJ0NClRo
aXMgbWVhbnMgaXQgd2lsbCBrZWVwIHdyaXRpbmcgbG9ncyB0byB0aGUgZm9s ZGVyIHNwZWNpZmll
ZCBmb3JldmVyLCBhbmQgd2l0aG91dCBhbiBpbnRlcnZlbnRpb24sIHRoZSBt ZWRpYSB3aWxsIHJ1
biBvdXQgb2Ygc3BhY2UuDQoNCldoYXQgZG8geW91IGd1eXMgZG8gd2l0aCBy ZWdhcmRzIHRvIHRo
aXMgc2l0dWF0aW9uLCBmb3IgZXhhbXBsZToNCkhvdyB0byB5b3UgY2xlYW4g dXAgdGhlIG9sZCBh
cmNoaXZlZCBsb2dzPw0KDQpGb3IgZXhhbXBsZToNCnlvdSBhcmNoaXZlIHlv dXIgbG9nIGZpbGVz
IGZyb20geW91ciBtYWluIFBvc3RncmVzIHNlcnZlciB0byBhIGZvbGRlciAv bW50L3BpdHIgZm9y
IGV4YW1wbGUNCllvdSBzZXQgeW91ciBzdGFuZGJ5IHRvIHBpY2sgdGhlIGxv Z3MgZnJvbSAvbW50
L3BpdHIsIHRoZW4gaXQgYXJjaGl2ZXMgZWFjaCBsb2cgYXMgaXQgY29tZXMu DQovbW50L3BpdHIg
d2lsbCBmaWxsIHVwIHZlcnkgcXVpY2tseSBhbmQgcnVuIG91dCBvZiBzcGFj ZSBpZiB3ZSBkb27i
gJl0IGhhdmUgYSBwcm9jZXNzIHRvIERFTEVURS9BUkNISUVWRSBvbGRlciBs b2dzLg0KDQpJIGd1
ZXNzIHRoZSBwcm9jZXNzIHdoaWNoIHBpY2tzIHVwIHRoZSBsb2dzIGZvciB0 aGUgc3RhbmRieSBz
ZXJ2ZXIsIG5lZWRzIHRvIHRha2UgY2FyZSBvZiB0aGUgbG9ncywgYnkgZGVs ZXRpbmcgdGhlIG9s
ZGVyIG9uZXMgb3IgYnkgYXJjaGl2aW5nIHRoZW0gcGVybWFuZW50bHk/DQpE ZXBlbmRzIG9uIHdo
YXQgaXQgaXMgeW91J3JlIHRyeWluZyB0byBhY2NvbXBsaXNoOg0KDQoNCiop IFBJVFIgc2xhdmUg
c2VydmVyIGNvbnN0YW50bHkgYXBwbHlpbmcgbG9ncw0KDQogICBJZiBhbGwg eW91IHdhbnQgaXMg
YSBzZXJ2ZXIgdG8gY29uc3RhbnRseSBhcHBseSB0aGUgbG9ncyBhbmQgeW91 IGRvbid0IGNhcmUg
YWJvdXQgdGhlbSBhZnRlcndhcmRzLCBsb29rIGludG8gdGhlICclcicgbWFj cm8gaW4gcGdfc3Rh
bmRieS4gIEl0IHdpbGwgYXV0b21hdGljYWxseSBhcmNoaXZlIGZpbGVzIGZv ciB5b3UgLS0gT2Yg
Y291cnNlLCB5b3VyIHN0YW5kYnkgaW5zdGFuY2UgbmVlZHMgdG8gaGF2ZSB3 cml0ZSBhY2Nlc3Mg
dG8gdGhlIC9tbnQvcGl0ciBmb2xkZXIgdG8gZGVsZXRlIGZyb20uDQoNCiAg IElmIHlvdSBhcmUg
dXNpbmcgdGhlIGFyY2hpdmVfY29tbWFuZCB0byBjb3B5IGZpbGVzIGluIHRo ZSAvbW50L3BpdHIg
ZGlyZWN0b3J5LCBhbmQgdGhlbiBkb2luZyBhIGNyb24gYmFzZWQgY29weSB0 byBhIGJhY2t1cCBz
ZXJ2ZXIsIGhhdmUgeW91ciBjcm9uam9iIGRlbGV0ZSBmaWxlcyBmcm9tIHRo ZSBwcmltYXJ5IGFm
dGVyIGl0IGlzIGNvbmZpcm1lZCB0aGF0IHRoZSBsb2dzIGdvdCBzaGlwcGVk IHNhZmVseSB0byB0
aGUgYmFja3VwLg0KDQoqKSBCYWNrdXAgcmV0ZW50aW9uIHRpbWUNCg0KICAg SWYgeW91J3JlIHRy
eWluZyB0byBrZWVwIGxvZ3MgYXJvdW5kIHNvIHRoYXQgeW91IGNhbiBkbyBh IHBvaW50IGluIHRp
bWUgcmVjb3Zlcnkgd2l0aCBvbGQgYmFja3VwcywgeW91IHdhbnQgdG8gZmln dXJlIHlvdXIgcmV0
ZW50aW9uIHRpbWVzIGFuZCBkZXRlcm1pbmUgeW91ciBSVE8gKGh0dHA6Ly9l bi53aWtpcGVkaWEu
b3JnL3dpa2kvUmVjb3ZlcnlfdGltZV9vYmplY3RpdmUpLg0KDQogICAgIElm IHlvdSBuZWVkIHRv
IGJlIGFibGUgdG8gcmVjb3ZlcnkgdG8gYW55IHBvaW50IGluIHRpbWUgZm9y IHRoZSBwYXN0IDEg
d2VlayB3aXRoIGEgbG93IFJUTywgdGhlbiB5b3Ugd2FudCB0byBrZWVwIHRo YXQgd2VlaydzIHdv
cnRoIG9mIGxvZ3MgdW5jb21wcmVzc2VkIGFuZCBhdmFpbGFibGUuICBBbnl0 aGluZyBiZXlvbmQg
dGhhdCwgdXNlIGEgY3JvbiBqb2IgdG8gY29tcHJlc3MgdGhlIGxvZ3MgKHRo ZXkgdXN1YWxseSBj
b21wcmVzcyBwcmV0dHkgd2VsbCBiYXNlZCBvbiB5b3VyIGRhdGEpLg0KDQog ICAgIEJhc2ljYWxs
eSwgeW91IG5lZWQgdG8ga2VlcCBhbGwgdGhlIGxvdy1SVE8gcmVxdWlyZWQg bG9ncyBhcm91bmQg
c28gdGhhdCB5b3UgY2FuIHF1aWNrbHkgZ2V0IGF0IHRoZW0uICBJZiB5b3Ug ZG9uJ3QgaGF2ZSBh
bnkgbG93IFJUTyByZXF1aXJlbWVudHMgYW5kIHlvdSBqdXN0IHdhbnQgdG8g a2VlcCBhIGZldyB3
ZWVrcyB3b3J0aCBvZiBkYXRhIGFyb3VuZCwgSSB3b3VsZCByZWNvbW1lbmQg dGhhdCB5b3UgYWRk
IGEgZmV3IGxpbmVzIG9mIGNvZGUgdG8gdGhlIGVuZCBvZiB5b3VyIGJhY2t1 cCBqb2IgdG8gY29t
cHJlc3MgKG9yIHlvdSBjb3VsZCBkZWxldGUgaWYgeW91IGRvbid0IHdhbnQg dGhlbSkgYWxsIHRo
ZSBsb2dzIHByaW9yIHRvIHRoZSBiYWNrdXAgdGhhdCB5b3UgYXJlIHRha2lu Zy4NCg0KSG9wZSB0
aGlzIGhlbHBzDQoNCi0tU2NvdHQNCg0KDQpIb3cgZG8geW91IGd1eXMgZGVh bCB3aXRoIHRoaXMg
cHJvYmxlbT8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNlDQoN CkJlc3QgcmVnYXJk
cw0KDQpSZW5hdG8NCg0KDQoNClJlbmF0byBPbGl2ZWlyYQ0KU3lzdGVtcyBB ZG1pbmlzdHJhdG9y
DQplLW1haWw6IHJlbmF0by5vbGl2ZWlyYUBncmFudC5jby51azxtYWlsdG86 cmVuYXRvLm9saXZl
aXJhQGdyYW50LmNvLnVrPg0KDQpUZWw6ICs0NCAoMCkxNzYzIDI2MDgxMQ0K RmF4OiArNDQgKDAp
MTc2MyAyNjI0MTANCnd3dy5ncmFudC5jby51azxodHRwOi8vd3d3LmdyYW50 LmNvLnVrLz4NCg0K
R3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRkDQoNCkNvbXBhbnkg cmVnaXN0ZXJlZCBp
biBFbmdsYW5kLCByZWdpc3RyYXRpb24gbnVtYmVyIDY1ODEzMw0KDQpSZWdp c3RlcmVkIG9mZmlj
ZSBhZGRyZXNzOg0KMjkgU3RhdGlvbiBSb2FkLA0KU2hlcHJldGgsDQpDQU1C UyBTRzggNkdCDQpV
Sw0KDQoNCg0KDQoNClAgUGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVu dCBiZWZvcmUgcHJp
bnRpbmcgdGhpcyBlbWFpbA0KQ09ORklERU5USUFMSVRZOiBUaGUgaW5mb3Jt YXRpb24gaW4gdGhp
cyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwu IEl0IGlzIGludGVu
ZGVkIG9ubHkgZm9yIHRoZSBuYW1lZCByZWNpcGllbnRzKHMpLiBJZiB5b3Ug YXJlIG5vdCB0aGUg
bmFtZWQgcmVjaXBpZW50IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQg
ZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbm90aGVyIHBlcnNv biBvciB0YWtlIGNv
cGllcy4NCg0KVklSVVNFUzogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWls IG9yIGF0dGFjaG1l
bnQocykgbWF5IGNvbnRhaW4gdmlydXNlcyB3aGljaCBjb3VsZCBkYW1hZ2Ug eW91ciBvd24gY29t
cHV0ZXIgc3lzdGVtLiBXaGlsc3QgR3JhbnQgSW5zdHJ1bWVudHMgKENhbWJy aWRnZSkgTHRkIGhh
cyB0YWtlbiBldmVyeSByZWFzb25hYmxlIHByZWNhdXRpb24gdG8gbWluaW1p c2UgdGhpcyByaXNr
LCB3ZSBjYW5ub3QgYWNjZXB0IGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSB3 aGljaCB5b3Ugc3Vz
dGFpbiBhcyBhIHJlc3VsdCBvZiBzb2Z0d2FyZSB2aXJ1c2VzLiBZb3Ugc2hv dWxkIHRoZXJlZm9y
ZSBjYXJyeSBvdXQgeW91ciBvd24gdmlydXMgY2hlY2tzIGJlZm9yZSBvcGVu aW5nIHRoZSBhdHRh
Y2htZW50KHMpLg0KDQpPcGVuWE1MOiBGb3IgaW5mb3JtYXRpb24gYWJvdXQg dGhlIE9wZW5YTUwg
ZmlsZSBmb3JtYXQgaW4gdXNlIHdpdGhpbiBHcmFudCBJbnN0cnVtZW50cyBw bGVhc2UgdmlzaXQg
b3VyIHdlYnNpdGU8aHR0cDovL3d3dy5ncmFudC5jby51ay9TdXBwb3J0L29w ZW54bWwuaHRtbD4N
Cg0KDQoNCg0KUCBQbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJl Zm9yZSBwcmludGlu
ZyB0aGlzIGVtYWlsDQpDT05GSURFTlRJQUxJVFk6IFRoZSBpbmZvcm1hdGlv biBpbiB0aGlzIGUt
bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbC4gSXQg aXMgaW50ZW5kZWQg
b25seSBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudHMocykuIElmIHlvdSBhcmUg bm90IHRoZSBuYW1l
ZCByZWNpcGllbnQgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBu
b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFub3RoZXIgcGVyc29uIG9y IHRha2UgY29waWVz
Lg0KDQpWSVJVU0VTOiBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgb3Ig YXR0YWNobWVudChz
KSBtYXkgY29udGFpbiB2aXJ1c2VzIHdoaWNoIGNvdWxkIGRhbWFnZSB5b3Vy IG93biBjb21wdXRl
ciBzeXN0ZW0uIFdoaWxzdCBHcmFudCBJbnN0cnVtZW50cyAoQ2FtYnJpZGdl KSBMdGQgaGFzIHRh
a2VuIGV2ZXJ5IHJlYXNvbmFibGUgcHJlY2F1dGlvbiB0byBtaW5pbWlzZSB0 aGlzIHJpc2ssIHdl
IGNhbm5vdCBhY2NlcHQgbGlhYmlsaXR5IGZvciBhbnkgZGFtYWdlIHdoaWNo IHlvdSBzdXN0YWlu
IGFzIGEgcmVzdWx0IG9mIHNvZnR3YXJlIHZpcnVzZXMuIFlvdSBzaG91bGQg dGhlcmVmb3JlIGNh
cnJ5IG91dCB5b3VyIG93biB2aXJ1cyBjaGVja3MgYmVmb3JlIG9wZW5pbmcg dGhlIGF0dGFjaG1l
bnQocykuDQoNCk9wZW5YTUw6IEZvciBpbmZvcm1hdGlvbiBhYm91dCB0aGUg T3BlblhNTCBmaWxl
IGZvcm1hdCBpbiB1c2Ugd2l0aGluIEdyYW50IEluc3RydW1lbnRzIHBsZWFz ZSB2aXNpdCBvdXIg
d2Vic2l0ZTxodHRwOi8vd3d3LmdyYW50LmNvLnVrL1N1cHBvcnQvb3Blbnht bC5odG1sPg0K
--_000_7965A9DCF12CC14984420BCC37B1608F25AC0B99E6Elzargrantc ou_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
77u/PEhUTUwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiIHhtbG5zOm09
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIv b21tbCIgeG1sbnM6
bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp2PSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0
LWNvbTpvZmZpY2U6d29yZCI+PGhlYWQ+PE1FVEEgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0
PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KPE1FVEEgY29u dGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi Pg0KDQo8bWV0YSBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBl
Pg0KPG1ldGEgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVk IG1lZGl1bSkiIG5h
bWU9R2VuZXJhdG9yPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOiog e2JlaGF2aW9yOnVy
bCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVs dCNWTUwpO30NCndc
Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVo YXZpb3I6dXJsKCNk
ZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPg0KPHN0eWxl Pg0KPCEtLQ0KIC8q
IEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZh
bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXZWJkaW5nczsNCglwYW5vc2UtMTo1IDMgMSAy IDEgNSA5IDYgNyAz
O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpz
cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBh Z2UgU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4N Cjwvc3R5bGU+DQo8
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4
bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1h cCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hl
YWQ+PEJPRFk+DQo8RElWIFNUWUxFPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1G QU1JTFk6IENvdXJp
ZXIgTmV3Ij4NCjxESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpF PSIyIj4NCg0KPGRp
diBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjoj
MUY0OTdEJz5JIHdhcyBsb29raW5nIGludG8gU2t5VG9vbHMsIGl0IHNvdW5k cyBxdWl0ZSBnb29k
LiBJIGFtIGdvaW5nIHRvDQpyZXZpc2l0IHRoaXMgUElUUiBzb2x1dGlvbiBv bmNlIGl0IGlzIGlt
cGxlbWVudGVkIGZvciBzdXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5XaWxsIHRyeSB0byBr ZWVwIGFuIGV5ZSBh
bmQgc2VlIGhvdyBpdCBnb2VzIG9uIGxpdmUgYW5kIHNlZSB3aGF0DQp3ZSBu ZWVkIHRvIGFkanVz
dCBpbiB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1z
ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMxRjQ5
N0QnPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgaGVscCByZWFsbHkg YXBwcmVjaWF0ZWQg
aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsN
CmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5SZW5hdG88bzpw PjwvbzpwPjwvc3Bh
bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIEZB
Q0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIEZBQ0U9
IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+ UmVuYXRvIE9saXZl
aXJhPEJSPlN5c3RlbXMgQWRtaW5pc3RyYXRvcjxCUj5lLW1haWw6IHJlbmF0 by5vbGl2ZWlyYUBn
cmFudC5jby51azwvRk9OVD48L0ZPTlQ+PEZPTlQgRkFDRT0iQXJpYWwiIFNJ WkU9IjIiPjxGT05U
IEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBG
QUNFPSJBcmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9 IjIiPjwvRk9OVD48
L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBT SVpFPSIyIj48Rk9O
VCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+VGVsOiArNDQgKDApMTc2MyAyNjA4 MTE8QlI+RmF4OiAr
NDQgKDApMTc2MyAyNjI0MTA8QlI+PEEgSFJFRj0iaHR0cDovL3d3dy5ncmFu dC5jby51ay8iPnd3
dy5ncmFudC5jby51azwvQT48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBGQUNFPSJB
cmlhbCIgU0laRT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjwv Rk9OVD48L0ZPTlQ+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIy Ij48Rk9OVCBGQUNF
PSJBcmlhbCIgU0laRT0iMiI+R3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRn ZSkgTHRkIDxCUj4m
bmJzcDs8QlI+Q29tcGFueSByZWdpc3RlcmVkIGluIEVuZ2xhbmQsIHJlZ2lz dHJhdGlvbiBudW1i
ZXIgNjU4MTMzPEJSPiZuYnNwOzxCUj5SZWdpc3RlcmVkIG9mZmljZSBhZGRy ZXNzOjxCUj4yOSBT
dGF0aW9uIFJvYWQsIDxCUj5TaGVwcmV0aCwgPEJSPkNBTUJTIFNHOCA2R0Ig PEJSPlVLPC9GT05U
PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9 IjIiPjxGT05UIEZB
Q0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9 IkFyaWFsIiBTSVpF
PSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PC9GT05UPjwvRk9O VD4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjxGT05UIEZB Q0U9IkFyaWFsIiBT
SVpFPSIyIj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBGQUNF PSJBcmlhbCIgU0la
RT0iMiI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9IjIiPjwvRk9OVD48L0ZP TlQ+Jm5ic3A7PC9E
SVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48Rk9OVCBG QUNFPSJBcmlhbCIg
U0laRT0iMiI+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5n PUVOLVVTIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNh bnMtc2VyaWYiJz5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsN
CmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFZpdGFseSBC dXJzaHRleW4NCltt
YWlsdG86dmJ1cnNodGV5bkBicm9hZHdheS5jb21dIDxicj4NCjxiPlNlbnQ6 PC9iPiAxNSBBcHJp
bCAyMDEwIDE3OjA4PGJyPg0KPGI+VG86PC9iPiBzY290dC5saXN0c0BlbnRl cnByaXNlZGIuY29t
OyBSZW5hdG8gT2xpdmVpcmE8YnI+DQo8Yj5DYzo8L2I+IHBnc3FsLWFkbWlu QHBvc3RncmVzcWwu
b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQURNSU5dIGFyY2hpdmVk IFdBTEwgZmlsZXMg
cXVlc3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29O
b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y Om5hdnknPldlDQpt
YW5hZ2UgdGhlIFdBTCBmaWxlcyB2aWEgc2t5dG9vbHMgV0FMTUdSPGJyPg0K PGJyPg0KQXMgZmFy
IGFzIGxvZyBmaWxlcyB3ZSBydW4gYSBiYWNrdXAgZXZlcnkgMyBob3VzZSBh bmQga2VlcCAxMiBo
b3VzZXJzIHdvcnRoIG9uDQp0aGUgc2VydmVyLCBldmVyeXRoaW5nIGVsc2Ug aXMgc2VudCB0byBh
bWF6b24gUzMgdmlhIHMzc3luYzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PGRpdiBhbGlnbj1j
ZW50ZXIgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRl cic+DQoNCjxociBh
bGlnbj1jZW50ZXIgc2l6ZT0yIHdpZHRoPSIxMDAlIj4NCg0KPC9kaXY+DQoN CjxwIGNsYXNzPU1z
b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFo
b21hIiwic2Fucy1zZXJpZiInPkZyb208L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+Og0K cGdzcWwtYWRtaW4t
b3duZXJAcG9zdGdyZXNxbC5vcmcgJmx0O3Bnc3FsLWFkbWluLW93bmVyQHBv c3RncmVzcWwub3Jn
Jmd0OyA8YnI+DQo8Yj5UbzwvYj46IFJlbmF0byBPbGl2ZWlyYSAmbHQ7cmVu YXRvLm9saXZlaXJh
QGdyYW50LmNvLnVrJmd0OyA8YnI+DQo8Yj5DYzwvYj46IHBnc3FsLWFkbWlu QHBvc3RncmVzcWwu
b3JnICZsdDtwZ3NxbC1hZG1pbkBwb3N0Z3Jlc3FsLm9yZyZndDsgPGJyPg0K PGI+U2VudDwvYj46
IFRodSBBcHIgMTUgMTE6NTY6NDQgMjAxMDxicj4NCjxiPlN1YmplY3Q8L2I+ OiBSZTogW0FETUlO
XSBhcmNoaXZlZCBXQUxMIGZpbGVzIHF1ZXN0aW9uIDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCg0K
PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8 ZGl2Pg0KDQo8cCBj
bGFzcz1Nc29Ob3JtYWw+T24gVGh1LCBBcHIgMTUsIDIwMTAgYXQgMTE6MzEg QU0sIFJlbmF0byBP
bGl2ZWlyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlbmF0by5vbGl2ZWlyYUBn cmFudC5jby51ayI+
cmVuYXRvLm9saXZlaXJhQGdyYW50LmNvLnVrPC9hPiZndDsNCndyb3RlOjxv OnA+PC9vOnA+PC9w
Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90
dG9tLWFsdDphdXRvJz5EZWFyDQphbGwsPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0
OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9
J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5JDQp3
YXMgcmVhZGluZyBhZ2FpbiB0aGUgZG9jdW1lbnRhdGlvbi4uLiDigJxUaGUg YXJjaGl2ZSBjb21t
YW5kIHNob3VsZCBnZW5lcmFsbHkgZGUNCmRlc2lnbmVkIHRvIHJlZnVzZSB0 byBvdmVyd3JpdGUg
YW55IHByZS1leGlzdGluZyBhcmNoaXZlIGZpbGUu4oCdPG86cD48L286cD48 L3A+DQoNCjxwIGNs
YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8nPlRoaXMNCm1lYW5zIGl0IHdpbGwga2VlcCB3cml0 aW5nIGxvZ3MgdG8g
dGhlIGZvbGRlciBzcGVjaWZpZWQgZm9yZXZlciwgYW5kIHdpdGhvdXQgYW4N CmludGVydmVudGlv
biwgdGhlIG1lZGlhIHdpbGwgcnVuIG91dCBvZiBzcGFjZS48bzpwPjwvbzpw PjwvcD4NCg0KPHAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0
OmF1dG8nPldoYXQNCmRvIHlvdSBndXlzIGRvIHdpdGggcmVnYXJkcyB0byB0 aGlzIHNpdHVhdGlv
biwgZm9yIGV4YW1wbGU6PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHls
ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPkhv
dw0KdG8geW91IGNsZWFuIHVwIHRoZSBvbGQgYXJjaGl2ZWQgbG9ncz88bzpw PjwvbzpwPjwvcD4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8nPkZvcg0KZXhhbXBsZTo8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNv
Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1h
bHQ6YXV0byc+eW91DQphcmNoaXZlIHlvdXIgbG9nIGZpbGVzIGZyb20geW91 ciBtYWluIFBvc3Rn
cmVzIHNlcnZlciB0byBhIGZvbGRlciAvbW50L3BpdHIgZm9yDQpleGFtcGxl PG86cD48L286cD48
L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPllvdQ0Kc2V0IHlvdXIgc3Rh bmRieSB0byBwaWNr
IHRoZSBsb2dzIGZyb20gL21udC9waXRyLCB0aGVuIGl0IGFyY2hpdmVzIGVh Y2ggbG9nIGFzDQpp
dCBjb21lcy48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+L21udC9waXRy
DQp3aWxsIGZpbGwgdXAgdmVyeSBxdWlja2x5IGFuZCBydW4gb3V0IG9mIHNw YWNlIGlmIHdlIGRv
buKAmXQgaGF2ZSBhIHByb2Nlc3MgdG8NCkRFTEVURS9BUkNISUVWRSBvbGRl ciBsb2dzLjxvOnA+
PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpw PjwvbzpwPjwvcD4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SQ0KZ3Vlc3MgdGhlIHByb2Nlc3Mg d2hpY2ggcGlja3Mg
dXAgdGhlIGxvZ3MgZm9yIHRoZSBzdGFuZGJ5IHNlcnZlciwgbmVlZHMgdG8g dGFrZQ0KY2FyZSBv
ZiB0aGUgbG9ncywgYnkgZGVsZXRpbmcgdGhlIG9sZGVyIG9uZXMgb3IgYnkg YXJjaGl2aW5nIHRo
ZW0gcGVybWFuZW50bHk/PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KPC9k
aXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPkRl
cGVuZHMgb24gd2hhdCBpdCBpcyB5b3UncmUgdHJ5aW5nIHRvIGFjY29tcGxp c2g6PG86cD48L286
cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJz
cDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PG86
cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3Jt
YWw+KikgUElUUiBzbGF2ZSBzZXJ2ZXIgY29uc3RhbnRseSBhcHBseWluZyBs b2dzPG86cD48L286
cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJz
cDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+Jm5i
c3A7Jm5ic3A7IElmIGFsbCB5b3Ugd2FudCBpcyBhIHNlcnZlciB0byBjb25z dGFudGx5IGFwcGx5
DQp0aGUgbG9ncyBhbmQgeW91IGRvbid0IGNhcmUgYWJvdXQgdGhlbSBhZnRl cndhcmRzLCBsb29r
IGludG8gdGhlICclcicgbWFjcm8gaW4NCnBnX3N0YW5kYnkuICZuYnNwO0l0 IHdpbGwgYXV0b21h
dGljYWxseSBhcmNoaXZlIGZpbGVzIGZvciB5b3UgLS0gT2YgY291cnNlLA0K eW91ciBzdGFuZGJ5
IGluc3RhbmNlIG5lZWRzIHRvIGhhdmUgd3JpdGUgYWNjZXNzIHRvIHRoZSAv bW50L3BpdHIgZm9s
ZGVyIHRvDQpkZWxldGUgZnJvbS48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoN
CjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxk
aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsgSWYgeW91 IGFyZSB1c2luZyB0
aGUgYXJjaGl2ZV9jb21tYW5kIHRvIGNvcHkNCmZpbGVzIGluIHRoZSAvbW50 L3BpdHIgZGlyZWN0
b3J5LCBhbmQgdGhlbiBkb2luZyBhIGNyb24gYmFzZWQgY29weSB0byBhIGJh Y2t1cA0Kc2VydmVy
LCBoYXZlIHlvdXIgY3JvbmpvYiBkZWxldGUgZmlsZXMgZnJvbSB0aGUgcHJp bWFyeSBhZnRlciBp
dCBpcyBjb25maXJtZWQNCnRoYXQgdGhlIGxvZ3MgZ290IHNoaXBwZWQgc2Fm ZWx5IHRvIHRoZSBi
YWNrdXAuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29O
b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFz
cz1Nc29Ob3JtYWw+KikgQmFja3VwIHJldGVudGlvbiB0aW1lPG86cD48L286 cD48L3A+DQoNCjwv
ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+
DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7Jm5ic3A7IElm
IHlvdSdyZSB0cnlpbmcgdG8ga2VlcCBsb2dzIGFyb3VuZCBzbyB0aGF0DQp5 b3UgY2FuIGRvIGEg
cG9pbnQgaW4gdGltZSByZWNvdmVyeSB3aXRoIG9sZCBiYWNrdXBzLCB5b3Ug d2FudCB0byBmaWd1
cmUgeW91cg0KcmV0ZW50aW9uIHRpbWVzIGFuZCBkZXRlcm1pbmUgeW91ciBS VE8gKDxhIGhyZWY9
Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUmVjb3ZlcnlfdGltZV9v YmplY3RpdmUiPmh0
dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUmVjb3ZlcnlfdGltZV9vYmpl Y3RpdmU8L2E+KS48
bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbD4mbmJzcDsmbmJzcDsgJm5ic3A7IElmIHlvdSBuZWVkIHRvIGJlIGFi bGUgdG8gcmVjb3Zl
cnkgdG8NCmFueSBwb2ludCBpbiB0aW1lIGZvciB0aGUgcGFzdCAxIHdlZWsg d2l0aCBhIGxvdyBS
VE8sIHRoZW4geW91IHdhbnQgdG8ga2VlcA0KdGhhdCB3ZWVrJ3Mgd29ydGgg b2YgbG9ncyB1bmNv
bXByZXNzZWQgYW5kIGF2YWlsYWJsZS4gJm5ic3A7QW55dGhpbmcgYmV5b25k DQp0aGF0LCB1c2Ug
YSBjcm9uIGpvYiB0byBjb21wcmVzcyB0aGUgbG9ncyAodGhleSB1c3VhbGx5 IGNvbXByZXNzIHBy
ZXR0eSB3ZWxsDQpiYXNlZCBvbiB5b3VyIGRhdGEpLiAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCg0K
PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwv
cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDsmbmJzcDsg
Jm5ic3A7IEJhc2ljYWxseSwgeW91IG5lZWQgdG8ga2VlcCBhbGwgdGhlDQps b3ctUlRPIHJlcXVp
cmVkIGxvZ3MgYXJvdW5kIHNvIHRoYXQgeW91IGNhbiBxdWlja2x5IGdldCBh dCB0aGVtLiAmbmJz
cDtJZiB5b3UNCmRvbid0IGhhdmUgYW55IGxvdyBSVE8gcmVxdWlyZW1lbnRz IGFuZCB5b3UganVz
dCB3YW50IHRvIGtlZXAgYSBmZXcgd2Vla3Mgd29ydGgNCm9mIGRhdGEgYXJv dW5kLCBJIHdvdWxk
IHJlY29tbWVuZCB0aGF0IHlvdSBhZGQgYSBmZXcgbGluZXMgb2YgY29kZSB0 byB0aGUgZW5kDQpv
ZiB5b3VyIGJhY2t1cCBqb2IgdG8gY29tcHJlc3MgKG9yIHlvdSBjb3VsZCBk ZWxldGUgaWYgeW91
IGRvbid0IHdhbnQgdGhlbSkgYWxsDQp0aGUgbG9ncyBwcmlvciB0byB0aGUg YmFja3VwIHRoYXQg
eW91IGFyZSB0YWtpbmcuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBj
bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0K
DQo8cCBjbGFzcz1Nc29Ob3JtYWw+SG9wZSB0aGlzIGhlbHBzPG86cD48L286 cD48L3A+DQoNCjwv
ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+
DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+LS1T Y290dDxvOnA+PC9v
OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9 J2JvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBw
dDsNCm1hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPg0KDQo8 ZGl2Pg0KDQo8ZGl2
Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9
J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SG93 DQpkbyB5b3UgZ3V5
cyBkZWFsIHdpdGggdGhpcyBwcm9ibGVtPzxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFs
dDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxl
PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+VGhh
bmsNCnlvdSB2ZXJ5IG11Y2ggaW4gYWR2YW5jZTxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9t
LWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0
eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+
QmVzdA0KcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9
J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+UmVu YXRvPG86cD48L286
cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KDQo8
cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjwv
ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bh
bj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPlJl
bmF0bw0KT2xpdmVpcmE8YnI+DQpTeXN0ZW1zIEFkbWluaXN0cmF0b3I8YnI+ DQplLW1haWw6IDxh
IGhyZWY9Im1haWx0bzpyZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWsiIHRh cmdldD0iX2JsYW5r
Ij5yZW5hdG8ub2xpdmVpcmFAZ3JhbnQuY28udWs8L2E+PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD48 L286cD48L3NwYW4+
PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxl
PSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMt
c2VyaWYiJz5UZWw6DQorNDQgKDApMTc2MyAyNjA4MTE8YnI+DQpGYXg6ICs0 NCAoMCkxNzYzIDI2
MjQxMDxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuZ3JhbnQuY28udWsvIiB0 YXJnZXQ9Il9ibGFu
ayI+d3d3LmdyYW50LmNvLnVrPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPC9k
aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFu
PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+R3Jh
bnQNCkluc3RydW1lbnRzIChDYW1icmlkZ2UpIEx0ZCA8YnI+DQombmJzcDs8 YnI+DQpDb21wYW55
IHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCwgcmVnaXN0cmF0aW9uIG51bWJlciA2 NTgxMzM8YnI+DQom
bmJzcDs8YnI+DQpSZWdpc3RlcmVkIG9mZmljZSBhZGRyZXNzOjxicj4NCjI5 IFN0YXRpb24gUm9h
ZCwgPGJyPg0KU2hlcHJldGgsIDxicj4NCkNBTUJTIFNHOCA2R0IgPGJyPg0K VUs8L3NwYW4+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXci
Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseToi
Q291cmllciBOZXciJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8
ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtm
b250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoN
CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8 bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9y
bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6
YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0n
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxlbT48
Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTguMHB0O2Zv bnQtZmFtaWx5Oldl
YmRpbmdzO2NvbG9yOmdyZWVuJz5QPC9zcGFuPjwvYj48L2VtPjxlbT48Yj48 c3BhbiBsYW5nPUVO
LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz4gPC9z cGFuPjwvYj48L2Vt
PjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtjb2xv cjpncmVlbic+UGxl
YXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUNCnByaW50aW5n IHRoaXMgZW1haWw8
L3NwYW4+PC9pPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0K
PHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkNPTkZJREVOVElB TElUWTwvc3Bhbj48
L3N0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwi
LCJzYW5zLXNlcmlmIic+OiBUaGUgaW5mb3JtYXRpb24gaW4NCnRoaXMgZS1t YWlsIGFuZCBhbnkg
YXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBv bmx5IGZvciB0aGUN
Cm5hbWVkIHJlY2lwaWVudHMocykuIElmIHlvdSBhcmUgbm90IHRoZSBuYW1l ZCByZWNpcGllbnQg
cGxlYXNlIG5vdGlmeSB0aGUNCnNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3Nl
IHRoZSBjb250ZW50cyB0byBhbm90aGVyIHBlcnNvbiBvciB0YWtlDQpjb3Bp ZXMuIDwvc3Bhbj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5l
dyInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxw
IGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5WSVJVU0VTOjwvc3Bh bj48L3N0cm9uZz48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNl
cmlmIic+IFRoZSBjb250ZW50cyBvZiB0aGlzDQplLW1haWwgb3IgYXR0YWNo bWVudChzKSBtYXkg
Y29udGFpbiB2aXJ1c2VzIHdoaWNoIGNvdWxkIGRhbWFnZSB5b3VyIG93bg0K Y29tcHV0ZXIgc3lz
dGVtLiBXaGlsc3QgR3JhbnQgSW5zdHJ1bWVudHMgKENhbWJyaWRnZSkgTHRk IGhhcyB0YWtlbiBl
dmVyeQ0KcmVhc29uYWJsZSBwcmVjYXV0aW9uIHRvIG1pbmltaXNlIHRoaXMg cmlzaywgd2UgY2Fu
bm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueQ0KZGFtYWdlIHdoaWNoIHlv dSBzdXN0YWluIGFz
IGEgcmVzdWx0IG9mIHNvZnR3YXJlIHZpcnVzZXMuIFlvdSBzaG91bGQgdGhl cmVmb3JlDQpjYXJy
eSBvdXQgeW91ciBvd24gdmlydXMgY2hlY2tzIGJlZm9yZSBvcGVuaW5nIHRo ZSBhdHRhY2htZW50
KHMpLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJDb3Vy
aWVyIE5ldyInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoN
CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0 eWxlPSdmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5P cGVuWE1MPC9zcGFu
Pjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlh
bCIsInNhbnMtc2VyaWYiJz46IEZvciBpbmZvcm1hdGlvbg0KYWJvdXQgdGhl IE9wZW5YTUwgZmls
ZSBmb3JtYXQgaW4gdXNlIHdpdGhpbiBHcmFudCBJbnN0cnVtZW50cyBwbGVh c2UgdmlzaXQgb3Vy
IDxhIGhyZWY9Imh0dHA6Ly93d3cuZ3JhbnQuY28udWsvU3VwcG9ydC9vcGVu eG1sLmh0bWwiIHRh
cmdldD0iX2JsYW5rIj53ZWJzaXRlPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0K
PC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ibG9ja3F1b3RlPg0K DQo8L2Rpdj4NCg0K
PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8 L2Rpdj4NCg0KPC9G
T05UPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIEZBQ0U9IkFy
aWFsIiBTSVpFPSIyIj48Rk9OVCBGQUNFPSJBcmlhbCIgU0laRT0iMiI+PC9G T05UPjwvRk9OVD48
L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+IDwvRElWPg0KPERJVj4NCjxQIENM QVNTPSJNc29Ob3Jt
YWwiPjxFTT48Qj48U1BBTiBMQU5HPSJFTi1VUyIgU1RZTEU9IkZPTlQtU0la RTogMThwdDsgQ09M
T1I6IGdyZWVuOyBGT05ULUZBTUlMWTogV2ViZGluZ3MiPjwvU1BBTj48L0I+ PC9FTT4mbmJzcDs8
L1A+DQo8UCBDTEFTUz0iTXNvTm9ybWFsIj48RU0+PEI+PFNQQU4gTEFORz0i RU4tVVMiIFNUWUxF
PSJGT05ULVNJWkU6IDE4cHQ7IENPTE9SOiBncmVlbjsgRk9OVC1GQU1JTFk6 IFdlYmRpbmdzIj5Q
PC9TUEFOPjwvQj48L0VNPjxFTT48Qj48U1BBTiBMQU5HPSJFTi1VUyIgU1RZ TEU9IkZPTlQtU0la
RTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogJ1ZlcmRhbmEn LCdzYW5zLXNlcmlm
JyI+IDwvU1BBTj48L0I+PC9FTT48U1RST05HPjxJPjxTUEFOIFNUWUxFPSJG T05ULVNJWkU6IDcu
NXB0OyBDT0xPUjogZ3JlZW47IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5z LXNlcmlmJyI+UGxl
YXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcg dGhpcyBlbWFpbDwv
U1BBTj48L0k+PC9TVFJPTkc+PC9QPjwvRElWPg0KPERJVj48Rk9OVCBGQUNF PSJBcmlhbCIgU0la
RT0iMiI+PFNUUk9ORz5DT05GSURFTlRJQUxJVFk8L1NUUk9ORz46IFRoZSBp bmZvcm1hdGlvbiBp
biB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVu dGlhbC4gSXQgaXMg
aW50ZW5kZWQgb25seSBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudHMocykuIElm IHlvdSBhcmUgbm90
IHRoZSBuYW1lZCByZWNpcGllbnQgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5
IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFub3RoZXIg cGVyc29uIG9yIHRh
a2UgY29waWVzLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFy aWFsIiBTSVpFPSIy
Ij48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFs IiBTSVpFPSIyIj48
U1RST05HPjwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgRkFD RT0iQXJpYWwiIFNJ
WkU9IjIiPjxTVFJPTkc+VklSVVNFUzo8L1NUUk9ORz4gVGhlIGNvbnRlbnRz IG9mIHRoaXMgZS1t
YWlsIG9yIGF0dGFjaG1lbnQocykgbWF5IGNvbnRhaW4gdmlydXNlcyB3aGlj aCBjb3VsZCBkYW1h
Z2UgeW91ciBvd24gY29tcHV0ZXIgc3lzdGVtLiBXaGlsc3QgR3JhbnQgSW5z dHJ1bWVudHMgKENh
bWJyaWRnZSkgTHRkIGhhcyB0YWtlbiBldmVyeSByZWFzb25hYmxlIHByZWNh dXRpb24gdG8gbWlu
aW1pc2UgdGhpcyByaXNrLCB3ZSBjYW5ub3QgYWNjZXB0IGxpYWJpbGl0eSBm b3IgYW55IGRhbWFn
ZSB3aGljaCB5b3Ugc3VzdGFpbiBhcyBhIHJlc3VsdCBvZiBzb2Z0d2FyZSB2 aXJ1c2VzLiBZb3Ug
c2hvdWxkIHRoZXJlZm9yZSBjYXJyeSBvdXQgeW91ciBvd24gdmlydXMgY2hl Y2tzIGJlZm9yZSBv
cGVuaW5nIHRoZSBhdHRhY2htZW50KHMpLjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48L0ZPTlQ+PC9E SVY+DQo8RElWPjxG
T05UIEZBQ0U9IkFyaWFsIiBTSVpFPSIyIj48U1RST05HPk9wZW5YTUw8L1NU Uk9ORz46IEZvciBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgT3BlblhNTCBmaWxlIGZvcm1hdCBpbiB1 c2Ugd2l0aGluIEdy
YW50IEluc3RydW1lbnRzIHBsZWFzZSB2aXNpdCBvdXIgPEEgSFJFRj0iaHR0 cDovL3d3dy5ncmFu
dC5jby51ay9TdXBwb3J0L29wZW54bWwuaHRtbCI+d2Vic2l0ZTwvQT48L0ZP TlQ+PC9ESVY+PC9E
SVY+PC9CT0RZPjwvSFRNTD4NCg==
--_000_7965A9DCF12CC14984420BCC37B1608F25AC0B99E6Elzargrantc ou_--
Re: archived WALL files question
am 16.04.2010 18:29:02 von Frederiko Costa
This is a multi-part message in MIME format.
--------------020507000702050204090005
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Hi Renato,
I had the same question. I think, as far as I understood, the point is
that if you have a few base backups, not only logs replay would be
faster for a recovery but also you don't need to archive WAL segments
before the base backup.
**
I also have a question regarding the frequency of log shipping from the
primary server to a directory exported to the standby server. The
standby server is stopped ready to be launched in recovery mode. The
point is in the primary server. I noticed the new logs files don't get
copied to the directory specified on the archive_command. It's only
copied when I do the pg_start_backup()/pg_stop_backup() base backup. Is
this behaviour only achieved if I set archive_timeout? I did not want to
do that, because I thought as soon as the 16MB WAL segment file got
created it would be copied to the exported directory. Besides, I don't
think I would need to perform base backups frequently.
Any advice?
Thanks
On 04/16/2010 12:00 AM, Renato Oliveira wrote:
> I am sorry Kevin, I really appreciate your experience and your knowledge, and that's why I am asking; I thought the base backup was only necessary once. For example once you have done your first base backup, that is it, all you need is to replay the logs and backup the logs.
>
> What would be the reason(s) for you to do weekly base backups?
>
> Thank you very much
>
> Best regards
>
> Renato
>
>
>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> http://www.grant.co.uk/
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
> -----Original Message-----
>
>
> From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
> Sent: 15 April 2010 17:02
> To: Renato Oliveira; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] archived WALL files question
>
> Renato Oliveira wrote:
>
>
>> I was reading again the documentation... "The archive command
>> should generally de designed to refuse to overwrite any
>> pre-existing archive file." This means it will keep writing logs
>> to the folder specified forever, and without an intervention, the
>> media will run out of space.
>>
> Overwriting an existing file wouldn't help with that, since the
> filenames keep changing. It might, for example, prevent
> accidentally wiping out the WAL files from one database cluster with
> WAL files from another by copying the postgresql.conf file and
> neglecting to change the archive script.
>
>
>> What do you guys do with regards to this situation, for example:
>> How to you clean up the old archived logs?
>>
> We keep two weekly base backups and all the WAL files needed to
> recover from the earlier of the two to present. We also keep an
> archival copy of the first base backup of each month with just the
> WAL files needed to start it. We delete WAL files when no longer
> needed to support this retention policy. It's all pretty automatic
> based on bash scripts run from cron jobs.
>
> Of course, you'll want to tailor your strategy to your business
> needs.
>
> -Kevin
>
>
>
> -----Original Message-----
>
>
> P Please consider the environment before printing this email
> CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
>
> VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
>
> OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html
>
>
>
--------------020507000702050204090005
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
http-equiv=3D"Content-Type">
Hi Renato,
I had the same question. I think, as far as I understood, the point is
that if you have a few base backups, not only logs replay would be
faster for a recovery but also you don't need to archive WAL segments
before the base backup.
**
I also have a question regarding the frequency of log shipping=A0 from
the primary server to a directory exported to the standby server. The
standby server is stopped ready to be launched in recovery mode. The
point is in the primary server. I noticed the new logs files don't get
copied to the directory specified on the archive_command. It's only
copied when I do the pg_start_backup()/pg_stop_backup() base backup. Is
this behaviour only achieved if I set archive_timeout? I did not want
to do that, because I thought as soon as the 16MB WAL segment file got
created it would be copied to the exported directory. Besides, I don't
think I would need to perform base backups frequently.
Any advice?
Thanks
On 04/16/2010 12:00 AM, Renato Oliveira wrote:
cite=3D"mid:7965A9DCF12CC14984420BCC37B1608F25AC0B99E4@Elzar .grant.co.uk=
"
type=3D"cite">
I am sorry Kevin, I really appreciate your experience an=
d your knowledge, and that's why I am asking; I thought the base backup w=
as only necessary once. For example once you have done your first base ba=
ckup, that is it, all you need is to replay the logs and backup the logs.
What would be the reason(s) for you to do weekly base backups?
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail:
ira@grant.co.uk">renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http:=
//www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Kevin Grittner [
evin.Grittner@wicourts.gov">mailto:Kevin.Grittner@wicourts.g ov]
Sent: 15 April 2010 17:02
To: Renato Oliveira;
:pgsql-admin@postgresql.org">pgsql-admin@postgresql.org
Subject: Re: [ADMIN] archived WALL files question
Renato Oliveira
oliveira@grant.co.uk"><renato.oliveira@grant.co.uk> wrote:
I was reading again the documentation... "The archive =
command
should generally de designed to refuse to overwrite any
pre-existing archive file." This means it will keep writing logs
to the folder specified forever, and without an intervention, the
media will run out of space.
Overwriting an existing file wouldn't help with that, since the
filenames keep changing. It might, for example, prevent
accidentally wiping out the WAL files from one database cluster with
WAL files from another by copying the postgresql.conf file and
neglecting to change the archive script.
What do you guys do with regards to this situation, fo=
r example:
How to you clean up the old archived logs?
We keep two weekly base backups and all the WAL files needed to
recover from the earlier of the two to present. We also keep an
archival copy of the first base backup of each month with just the
WAL files needed to start it. We delete WAL files when no longer
needed to support this retention policy. It's all pretty automatic
based on bash scripts run from cron jobs.
Of course, you'll want to tailor your strategy to your business
needs.
-Kevin
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is co=
nfidential. It is intended only for the named recipients(s). If you are n=
ot the named recipient please notify the sender immediately and do not di=
sclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses=
which could damage your own computer system. Whilst Grant Instruments (C=
ambridge) Ltd has taken every reasonable precaution to minimise this risk=
, we cannot accept liability for any damage which you sustain as a result=
of software viruses. You should therefore carry out your own virus check=
s before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Gran=
t Instruments please visit our
"http://www.grant.co.uk/Support/openxml.html">http://www.gra nt.co.uk/Supp=
ort/openxml.html
--------------020507000702050204090005--
Re: archived WALL files question
am 16.04.2010 19:15:46 von Kevin Grittner
Renato Oliveira wrote:
> I thought the base backup was only necessary once. For example
> once you have done your first base backup, that is it, all you
> need is to replay the logs and backup the logs. What would be
> the reason(s) for you to do weekly base backups?
There are a few reasons, many of which are probably not applicable
to most environments.
(1) Most of our source databases are spread around the state --
some over 300 miles away (500 km for those with sane units of
measure). Management has mandated that we must have backups in our
central location which have been restored to confirm usability, as
well as a copy of the backup files in the source locations. We
don't have equipment at the source locations to keep a warm standby
running, so a recovery there would need to replay all WAL files
since the base backup. A weekly cycle for base backups keeps the
set of WAL files we need to keep relatively small and allows
relatively rapid recovery.
(2) Because of the large number of database clusters being backup
up (about 100), it is not feasible to actually have warm standbys
for all of them which we can just switch to in case of emergency.
We use one rather largish machine to host a all the "warm standby"
instances, just to make sure that the WAL files are applying without
error to the base backups. We keep three machines prepped and ready
to go for emergencies, but we have to do the whole PITR recovery
from the base backup to get a production-ready copy. Again, the
shorter the time from the base backup, the fewer WAL files to apply,
and the sooner we're ready to go.
(3) We're mandated to keep monthly archival "snapshot" backups, so
we just grab the first weekly base backup of each month, with the
minimum set of WAL files needed to get it running (determined by the
..backup file).
(4) A fair amount of paranoia. If any subtle bugs affecting corner
cases were ever to creep into the software, the affects would be
minimized by using a fresher base backup and fewer WAL files.
I have heard of people running warm standbys for months without
getting a fresh base, and for many users that may be the best
option. Our situation is pretty unique -- although when I say that,
people are usually quick to point out that so is everyone else's.
;-)
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 19.04.2010 15:00:59 von Renato Oliveira
Kevin,
Thank you very much. I understand the multiple base backups are only to red=
uce the amount of time it could take to actually restore or reply all the L=
OGS.
Because let's suppose; I create a base backup today 19/04/2010 then one yea=
r later, I need to use that base backup, I will have to play one year worth=
of logs.
It is an interesting setup you have there, but you must have loads of space=
for all of those backups.
How long does it take for base backup of one of your busy DBs?
Thank you Very much
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
Sent: 16 April 2010 18:16
To: Frederiko Costa; Renato Oliveira; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] archived WALL files question
Renato Oliveira wrote:
> I thought the base backup was only necessary once. For example
> once you have done your first base backup, that is it, all you
> need is to replay the logs and backup the logs. What would be
> the reason(s) for you to do weekly base backups?
There are a few reasons, many of which are probably not applicable
to most environments.
(1) Most of our source databases are spread around the state --
some over 300 miles away (500 km for those with sane units of
measure). Management has mandated that we must have backups in our
central location which have been restored to confirm usability, as
well as a copy of the backup files in the source locations. We
don't have equipment at the source locations to keep a warm standby
running, so a recovery there would need to replay all WAL files
since the base backup. A weekly cycle for base backups keeps the
set of WAL files we need to keep relatively small and allows
relatively rapid recovery.
(2) Because of the large number of database clusters being backup
up (about 100), it is not feasible to actually have warm standbys
for all of them which we can just switch to in case of emergency.
We use one rather largish machine to host a all the "warm standby"
instances, just to make sure that the WAL files are applying without
error to the base backups. We keep three machines prepped and ready
to go for emergencies, but we have to do the whole PITR recovery
from the base backup to get a production-ready copy. Again, the
shorter the time from the base backup, the fewer WAL files to apply,
and the sooner we're ready to go.
(3) We're mandated to keep monthly archival "snapshot" backups, so
we just grab the first weekly base backup of each month, with the
minimum set of WAL files needed to get it running (determined by the
..backup file).
(4) A fair amount of paranoia. If any subtle bugs affecting corner
cases were ever to creep into the software, the affects would be
minimized by using a fresher base backup and fewer WAL files.
I have heard of people running warm standbys for months without
getting a fresh base, and for many users that may be the best
option. Our situation is pretty unique -- although when I say that,
people are usually quick to point out that so is everyone else's.
;-)
-Kevin
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html
--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 19.04.2010 17:34:28 von Frederiko Costa
This is a multi-part message in MIME format.
--------------040508000308080208050200
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Hi Renato,
I had the same question. I think, as far as I understood, the point is
that if you have a few base backups, not only logs replay would be
faster for a recovery but also you don't need to archive WAL segments
before the base backup.
**
I also have a question regarding the frequency of log shipping from the
primary server to a directory exported to the standby server. The
standby server is stopped ready to be launched in recovery mode. The
point is in the primary server. I noticed the new logs files don't get
copied to the directory specified on the archive_command. It's only
copied when I do the pg_start_backup()/pg_stop_backup() base backup. Is
this behaviour only achieved if I set archive_timeout? I did not want to
do that, because I thought as soon as the 16MB WAL segment file got
created it would be copied to the exported directory. Besides, I don't
think I would need to perform base backups frequently.
Any advice?
Thanks
On 04/16/2010 12:00 AM, Renato Oliveira wrote:
> I am sorry Kevin, I really appreciate your experience and your knowledge, and that's why I am asking; I thought the base backup was only necessary once. For example once you have done your first base backup, that is it, all you need is to replay the logs and backup the logs.
>
> What would be the reason(s) for you to do weekly base backups?
>
> Thank you very much
>
> Best regards
>
> Renato
>
>
>
> Renato Oliveira
> Systems Administrator
> e-mail:renato.oliveira@grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> http://www.grant.co.uk/
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
> -----Original Message-----
>
>
> From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
> Sent: 15 April 2010 17:02
> To: Renato Oliveira;pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] archived WALL files question
>
> Renato Oliveira wrote:
>
>
>> I was reading again the documentation... "The archive command
>> should generally de designed to refuse to overwrite any
>> pre-existing archive file." This means it will keep writing logs
>> to the folder specified forever, and without an intervention, the
>> media will run out of space.
>>
> Overwriting an existing file wouldn't help with that, since the
> filenames keep changing. It might, for example, prevent
> accidentally wiping out the WAL files from one database cluster with
> WAL files from another by copying the postgresql.conf file and
> neglecting to change the archive script.
>
>
>> What do you guys do with regards to this situation, for example:
>> How to you clean up the old archived logs?
>>
> We keep two weekly base backups and all the WAL files needed to
> recover from the earlier of the two to present. We also keep an
> archival copy of the first base backup of each month with just the
> WAL files needed to start it. We delete WAL files when no longer
> needed to support this retention policy. It's all pretty automatic
> based on bash scripts run from cron jobs.
>
> Of course, you'll want to tailor your strategy to your business
> needs.
>
> -Kevin
>
>
>
> -----Original Message-----
>
>
> P Please consider the environment before printing this email
> CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
>
> VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
>
> OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit ourhttp://www.grant.co.uk/Support/openxml.html
>
>
>
--------------040508000308080208050200
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
http-equiv=3D"Content-Type">
Hi Renato,
I had the same question. I think, as far as I understood, the point is
that if you have a few base backups, not only logs replay would be
faster for a recovery but also you don't need to archive WAL segments
before the base backup.
**
I also have a question regarding the frequency of log shipping=A0 from
the primary server to a directory exported to the standby server. The
standby server is stopped ready to be launched in recovery mode. The
point is in the primary server. I noticed the new logs files don't get
copied to the directory specified on the archive_command. It's only
copied when I do the pg_start_backup()/pg_stop_backup() base backup. Is
this behaviour only achieved if I set archive_timeout? I did not want
to do that, because I thought as soon as the 16MB WAL segment file got
created it would be copied to the exported directory. Besides, I don't
think I would need to perform base backups frequently.
Any advice?
Thanks
On 04/16/2010 12:00 AM, Renato Oliveira wrote:
cite=3D"mid:7965A9DCF12CC14984420BCC37B1608F25AC0B99E4@Elzar .grant.co.uk=
"
type=3D"cite">
I am sorry Kevin, I really appreciate your experience an=
d your knowledge, and that's why I am asking; I thought the base backup w=
as only necessary once. For example once you have done your first base ba=
ckup, that is it, all you need is to replay the logs and backup the logs.
What would be the reason(s) for you to do weekly base backups?
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail:
href=3D"mailto:renato.oliveira@grant.co.uk">renato.oliveira@ grant.co.uk<=
/a>
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http:=
//www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: Kevin Grittner [
href=3D"mailto:Kevin.Grittner@wicourts.gov">mailto:Kevin.Gri ttner@wicour=
ts.gov]
Sent: 15 April 2010 17:02
To: Renato Oliveira;
href=3D"mailto:pgsql-admin@postgresql.org">pgsql-admin@postg resql.org
>
Subject: Re: [ADMIN] archived WALL files question
Renato Oliveira
href=3D"mailto:renato.oliveira@grant.co.uk"><renato.oliveira@grant.co=
..uk> wrote:
I was reading again the documentation... "The archive =
command
should generally de designed to refuse to overwrite any
pre-existing archive file." This means it will keep writing logs
to the folder specified forever, and without an intervention, the
media will run out of space.
Overwriting an existing file wouldn't help with that, si=
nce the
filenames keep changing. It might, for example, prevent
accidentally wiping out the WAL files from one database cluster with
WAL files from another by copying the postgresql.conf file and
neglecting to change the archive script.
What do you guys do with regards to this situation, fo=
r example:
How to you clean up the old archived logs?
We keep two weekly base backups and all the WAL files ne=
eded to
recover from the earlier of the two to present. We also keep an
archival copy of the first base backup of each month with just the
WAL files needed to start it. We delete WAL files when no longer
needed to support this retention policy. It's all pretty automatic
based on bash scripts run from cron jobs.
Of course, you'll want to tailor your strategy to your business
needs.
-Kevin
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is co=
nfidential. It is intended only for the named recipients(s). If you are n=
ot the named recipient please notify the sender immediately and do not di=
sclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses=
which could damage your own computer system. Whilst Grant Instruments (C=
ambridge) Ltd has taken every reasonable precaution to minimise this risk=
, we cannot accept liability for any damage which you sustain as a result=
of software viruses. You should therefore carry out your own virus check=
s before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Gran=
t Instruments please visit our
class=3D"moz-txt-link-freetext"
href=3D"http://www.grant.co.uk/Support/openxml.html">http:// www.grant.co=
..uk/Support/openxml.html
--------------040508000308080208050200--
Re: archived WALL files question
am 19.04.2010 18:41:17 von Kevin Grittner
Frederiko Costa wrote:
> I noticed the new logs files don't get copied to the directory
> specified on the archive_command. It's only copied when I do the
> pg_start_backup()/pg_stop_backup() base backup. Is this behaviour
> only achieved if I set archive_timeout? I did not want to do that,
> because I thought as soon as the 16MB WAL segment file got created
> it would be copied to the exported directory.
Have you actually been filling up any 16MB WAL file segments? How
have you determined that? What happens when you run (as a database
superuser) this command?:
SELECT pg_switch_xlog();
If the reason you don't want to set archive_timeout is that you
don't want 16MB files piling up when there is little or no activity,
you might want to consider using pglesslog or pg_clearxlogtail.
These can eliminate nearly all the cost of the more frequent logs.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 19.04.2010 19:10:14 von Frederiko Costa
This is a multi-part message in MIME format.
--------------000107020109030001020300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I have seen new 16 MB segments files created in pg_xlog directory as
time goes on. Honestly, I did not understand why it got created, because
I was running it on a VM and there was no activity. I got several new
segments.
If I run the command you asked, this is the output. Neither segment is
copied, nor a new segment file gets created:
select pg_switch_xlog();
pg_switch_xlog
----------------
0/81000088
(1 row)
Wasn't this command supposed to create a new segment file and copy the
last non-copied segments - using command specified at archive_command -
to the destination you defined?
I wanted to understand why the newly created wal segment files (with 16
MB each) did not copied automatically to the new place. What's the
criteria? They only get copied when I carry out a base backup.
Thanks for the help!
On 04/19/2010 09:41 AM, Kevin Grittner wrote:
> Frederiko Costa wrote:
>
>
>> I noticed the new logs files don't get copied to the directory
>> specified on the archive_command. It's only copied when I do the
>> pg_start_backup()/pg_stop_backup() base backup. Is this behaviour
>> only achieved if I set archive_timeout? I did not want to do that,
>> because I thought as soon as the 16MB WAL segment file got created
>> it would be copied to the exported directory.
>>
>
> Have you actually been filling up any 16MB WAL file segments? How
> have you determined that? What happens when you run (as a database
> superuser) this command?:
>
> SELECT pg_switch_xlog();
>
> If the reason you don't want to set archive_timeout is that you
> don't want 16MB files piling up when there is little or no activity,
> you might want to consider using pglesslog or pg_clearxlogtail.
> These can eliminate nearly all the cost of the more frequent logs.
>
> -Kevin
>
--------------000107020109030001020300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
http-equiv="Content-Type">
I have seen new 16 MB segments files
created in pg_xlog directory as time goes on. Honestly, I did not
understand why it got created, because I was running it on a VM and
there was no activity. I got several new segments.
If I run the command you asked, this is the output. Neither
segment is copied, nor a new segment file gets created:
select pg_switch_xlog();
pg_switch_xlog
----------------
0/81000088
(1 row)
Wasn't this command supposed to create a new segment file and copy the
last non-copied segments - using command specified at archive_command -
to the destination you defined?
I wanted to understand why the newly created wal segment files (with 16
MB each) did not copied automatically to the new place. What's the
criteria? They only get copied when I carry out a base backup.
Thanks for the help!
On 04/19/2010 09:41 AM, Kevin Grittner wrote:
type="cite">
Frederiko Costa wrote:
I noticed the new logs files don't get copied to the directory
specified on the archive_command. It's only copied when I do the
pg_start_backup()/pg_stop_backup() base backup. Is this behaviour
only achieved if I set archive_timeout? I did not want to do that,
because I thought as soon as the 16MB WAL segment file got created
it would be copied to the exported directory.
Have you actually been filling up any 16MB WAL file segments? How
have you determined that? What happens when you run (as a database
superuser) this command?:
SELECT pg_switch_xlog();
If the reason you don't want to set archive_timeout is that you
don't want 16MB files piling up when there is little or no activity,
you might want to consider using pglesslog or pg_clearxlogtail.
These can eliminate nearly all the cost of the more frequent logs.
-Kevin
--------------000107020109030001020300--
Re: archived WALL files question
am 19.04.2010 19:26:19 von Kevin Grittner
Frederiko Costa wrote:
> I have seen new 16 MB segments files created in pg_xlog directory
> as time goes on. Honestly, I did not understand why it got
> created, because I was running it on a VM and there was no
> activity. I got several new segments.
>
> If I run the command you asked, this is the output. Neither
> segment is copied, nor a new segment file gets created:
>
> select pg_switch_xlog();
> pg_switch_xlog
> ----------------
> 0/81000088
> (1 row)
What version of PostgreSQL is this?
What do you see if you run?:
show archive_command;
show archive_mode;
show archive_timeout;
Check your log file from the time you ran pg_switch_xlog to look for
any messages which might give a clue to what's happening.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 19.04.2010 19:49:51 von Frederiko Costa
On 04/19/2010 10:26 AM, Kevin Grittner wrote:
> Frederiko Costa wrote:
>
>> I have seen new 16 MB segments files created in pg_xlog directory
>> as time goes on. Honestly, I did not understand why it got
>> created, because I was running it on a VM and there was no
>> activity. I got several new segments.
>>
>> If I run the command you asked, this is the output. Neither
>> segment is copied, nor a new segment file gets created:
>>
>> select pg_switch_xlog();
>> pg_switch_xlog
>> ----------------
>> 0/81000088
>> (1 row)
>>
>
> What version of PostgreSQL is this?
>
8.4.3
>
> What do you see if you run?:
>
> show archive_command;
>
cp -p %p /mnt/data/%f
> show archive_mode;
>
on
> show archive_timeout;
>
1min
I have just enabled that. Now, log files are being copied directly to
the /mnt/data dir. However, the same segments are not in the pg_xlog
dir. Is this a default behaviour?
Must I set archive_timeout? I don't think I want that, because,
specially for the next few months, where the activity would be very
limited and I would get several zero written segments just because
timeout has been reached. Is this approach recommended anyway? Or is it
better to use this approach even having limited approach?
> Check your log file from the time you ran pg_switch_xlog to look for
> any messages which might give a clue to what's happening.
>
>
The log files did not write anything about pg_switch_xlog.
> -Kevin
>
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: archived WALL files question
am 19.04.2010 20:41:43 von Kevin Grittner
Frederiko Costa wrote:
> log files are being copied directly to the /mnt/data dir.
> However, the same segments are not in the pg_xlog
> dir. Is this a default behaviour?
Yes, the pg_xlog directory tries to keep a set of files ready to
receive WAL, and to hold it until the next checkpoint completes,
while the archive directory holds WAL files which have filled or
reached the archive_timeout limit. There can be some overlap, but
basically you can view the archive as "past" and pg_xlog as
"future", with some potential overlap in "the present".
> Must I set archive_timeout?
No, but once a database write occurs, you don't have it backed up
until the WAL file is written to the archive directory.
archive_timeout is for those who want some wall-clock bounds on how
much they can lose in, say, a drive failure. If the database can be
reloaded from some other source, or the data has no real value, it
may not pay to use this feature.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin